While I completely agree with Henric that the colour coding is integral to the QlikView experience, his post did leave me wondering. Does it always have to be green?

The answer: No, not always. At least, not when you are running your applications in the AJAX or web view clients on QlikView 11 that is.

Inspired by Henric’s post I decided to create a small document extension that let’s you change the selection colour to whatever colour you like! The example below shows a blue colour scheme applied to the Movies Database application. You can easily change these colours by modifying the NoGreen.CSS file in the extension directory.

Of course, this document extension is just a fun little hack that is provided free but also completely as-is. If you have any improvements or comments though, then I’d like to hear from you.

Download NoGreen.qar

Today the Qlik Fix! goes travel blogging. From April 22 to 25, QlikTech’s annual Global Partner Summit Qonnections will take place at the Fontainebleau in Miami Beach. Unfortunately I will not be there this year due to other plans, but I have attended the previous events and was also present last year.

Besides meeting up with old friends, making new ones and attending some excellent sessions, one of the nice perks of these events is the ability to do a little sightseeing on the side. With that in mind I decided to compile my list of things to see and do in Miami.

To see

Ocean Drive / Art Deco District : Miami features some gorgeous architecture, especially in the Art Deco district. As most of the buildings are beautifully lighted with neon at night, an evening stroll around Ocean Drive is also highly recommended.

The Everglades : You’ll need to rent a car to go there, but an air boat tour around the Everglades is a cool experience. Watch out for the alligators!

Key Biscayne Lighthouse : You’ll also need a car to get here, but the Key Biscayne lighthouse is a picturesque place to visit and also has a very nice beach.

Duck Tours South Beach (1661 James Avenue, near Lincoln Road): If you don’t want to rent a car (or walk a lot), Duck Tours is a very entertaining way to see South Beach, the harbor and some (supposedly) celebrity houses. Cruising down Ocean Drive in a truck/boat hybrid while the stereo pumps C&C Music Factory’s “Everybody Dance Now”, what more could you ask for?

From the movies/TV

Fontainebleau Resort and Spa : Yes, the location of Qonnections has appeared in many movies and TV shows. It’s the place where Goldfinger cheats at cards, where Tony Montana chills at the pool in Scarface and Whitney Houston performs her concert in The Bodyguard.

Love Hate Tattoo : located on 1360 Washington Avenue, this is the tattoo shop featured in the Miami Ink TV show. Just in case you want to get that QlikView tattoo

Johnny Rockets : on 728 Ocean Drive, the location where the infamous chainsaw scene (NSFW, unless you work for a drug cartel) from Scarface took place.

Shopping

Lincoln Road Mall : located in South Beach Lincoln Road Mall is a pedestrian-only promenade that offers loads of interesting stores. And yes, it also has an Apple store.

Aventura Mall : if you like shopping, then this is a place where you can easily spend an entire day. Every major chain is represented in this shopping center.

The beach

Of course, you cannot go to Miami Beach and not visit the beach! For those that do not like sand, there is also a boardwalk that runs along the beach and is quite nice for a casual stroll.

Nightlife

With the packed agenda it’s not really possible (or more to the point; advisable) to stay up very late and enjoy the nightlife. That said, if you want to grab a few drinks along Ocean Drive, look out for these places:

Mango’s Tropical Cafe (900 Ocean Drive) : Live latin music and dancers, a little tacky and definitely a tourist trap, but fun to visit at least once during your stay.

Clevelander (1020 Ocean Drive): Decent dance music and a poolside bar.

All the locations mentioned above are plotted in the map below (though I do need to figure out how to put titles on the markers, to be updated later):

And that’s it for my Miami travel tips. If there’s anything I missed (quite likely), feel free to add it in the comments section below. For those of you attending Qonnections this year, I wish you all an excellent conference and safe travels!

Update 2012/04/25: Just learned that Qonnections 2013 will be held at the Atlantis Resort in the Bahamas. See you there!

I usually advise my clients not to upgrade to a new major QlikView version until the SR1 release is available. You can imagine that I was quite excited when QlikView 11 SR1 was released little over a week ago, finally could my existing QlikView customers use the cool new features of QlikView 11! Notes! Session collaboration! Document extensions!

Unfortunately, my enthusiasm rapidly diminished when I did a SiB (Seeing is Believing, or QlikView Proof of Concept) last week. I found SR1 contained bugs that made it unworkable for me. Amongst other things, initial data reduction with section access was not working and actions assigned to text/button objects would not work on the iPad. QlikTech must have realized this as well, as the SR1 release is no longer available for download at this moment.

I am back on the initial release now, which, given previous experiences with initial releases,  has actually been working much better than expected for me. I would actually go so far as to say that it has been working perfectly for me, with the exception of one very annoying bug.

I like to use lots of tabs in my script, to nicely indent various levels in loops etc. , but also to neatly align aliases. I also like to jump around the script a lot, switching between tabs and often using my mouse to position the cursor or to double-click a field name to select and copy it. This is where QlikView 11 IR introduced a bug that is really annoying when you do a lot of script development; when there are tabs in a line, QlikView will often position the cursor in the wrong place, as shown in the image below.

I reported this bug back in January (ID 44840) and was told that it would be fixed in SR1. I noticed that it hadn’t been fixed in last week’s SR1, but hopefully it will be fixed when the real SR1 is released.

I promise my next post will be less rant-y In the mean time, I am quite interested to hear your thoughts and opinions about rolling out QlikView 11 IR at existing customers.

Update: QlikTech released a technical bulletin about the SR1 withdrawal.

Fortunately, there is an easy way to solve this. Instead of using the regular paste option, use paste special to paste the image as a bitmap.

In both Office 2007 and 2010, the paste special option can be accessed via the paste drop-down menu on the left of the Home tab/ribbon, or via the Ctrl + Alt + V keyboard shortcut.

That’s it!

• What a big “If” you have
• Nifty trick for INLINE tables
• EDX in QlikView

What a big “If” you have

In this post Chris Cammers describes a pretty cool and elegant method (reminiscent of decision tables) for dealing with big, nested if-statements. Chris’ method increases maintainability of your QlikView applications by ensuring that complicated logic can be modified with relatively little effort. Definitely something to have a look at. Click here for the full blog post.

Nifty trick for INLINE tables

As seen in a previous blog round-up, Bill Lay of The Qlik Board has a talent for discovering obscure menu options in QlikView. In this post, Bill describes a nifty trick that will save you time when creating INLINE tables based on an already existing field, for example to add an aggregation level. Click here for the full blog post.

EDX in QlikView

EDX allows you to trigger a QlikView Server task via an external event. As I’m currently working on a project that requires the use of EDX, I’ve been researching this subject quite a bit. One of the best articles that I came across is an introduction to EDX by Pablo Parnisari. In this introduction, Pablo describes what EDX is, how it is set up on the server-side and how you can trigger an EDX task using a macro in your QlikView application. In short, almost everything you want to know about EDX. The only thing that Pablo doesn’t explain is the meaning of the EDX acronym, if you know what it means please leave a comment Click here for the full blog post.

That’s it for my QlikView blog round-up. If you have some good articles or blog posts that you want to share, feel free to post them in the comments section.

To start with the last part, in my opinion it is important to apply calculations and business rules consistently across QlikView applications. Doing this manually takes a lot of time and is prone to errors. Besides that, it is just not a very fun task. Fortunately, a lot of this can be handled by setting up a multi tiered environment with one or more QVD layers (for more information on this, see Rob Wunderlich’s excellent “Understanding & Best Practices with QVD files” webinar and slides).

Sometimes however, you need to use calculations that cannot be (easily) pushed to a QVD layer, for example when calculating averages or using set analysis. How can you store those calculations in a central place so they can be reused?

The first step is to create an external file (or database) to store your variable definitions. In this example I have created an Excel file with 3 columns, Name, Expression and Comment.

In the next step, the data is loaded into QlikView as a table and a little bit of script loops through all the rows and creates the variables.

And that is all there is to it! The variables that were defined in the Excel file have now been created in the front-end, ready the be used. An example QVW with the full script can be downloaded below.

Download the example QVW and source data

The only downside to this method is that the comments are not being written to the the comment section of the variable, but are instead stored together with the expression. Fortunately, I will be putting up a guest post that deals with this very subject in the near future, so stay tuned!

As always, if you have any comments or questions, please post them below.

I use variables and label referencing extensively in my applications, but I never really tested what this means for performance. I have always assumed that using variables instead of direct expressions would have a slight impact on performance. I also suspected that using label referencing would result in significantly better performance (I will explain this later).

But was this really true? Triggered by DV’s question, I set up a small experiment to test my assumptions.

For those of you that are in a hurry or do not want to read a lot of text before reaching an unexciting conclusion: My experiment seems to indicate that there is a very, very small performance cost when using variables or label referencing instead of direct expressions. For all intents and purposes this difference is negligible however, resulting in only a roughly 0.3% slower calculation for the slowest option.

For those of you that want to see how I did it, and maybe pick up some techniques for identifying and resolving performance issues in your QlikView applications: Read on!

The set-up

As performance issues with calculation of objects are usually not an issue with small data volumes, I decided that I would need a moderate-to-large dataset to test with. I generated a 500 million row CSV file containing the following data:

• Customer: random customer names between AAA and ZZZ, resulting in 17,576 unique values;
• Product: random products named A to Z, 26 unique values;
• Year: random year from 2008 to 2011;
• Actual revenue: random number between 0 and 1,000,000;
• Target revenue: random number between 0 and 1,000,000.

This resulted in a 12.5 GB CSV file, that I then loaded into QlikView. (It also turned into a 4 GB QVD file, but that is the subject for another post)

I then created a very big pivot table containing actual and targeted revenue for each customer by product and year. Additionally, I created a calculated field to compare actual versus targeted revenue.

The idea was to create an object that contained many records and calculations, so that any differences in calculation speed between the various calculation options would be amplified.

The calculation options

For the expressions, I tested three different options to see how the calculation time would be affected:

• Direct expression: this is the straightforward option, directly typing the expression into the expression definition:
  • Actual revenue: sum(Actual)
  • Target revenue: sum(Target)
  • Actual vs Target: sum(Actual) / sum(Target)
• Label referencing: this option is the same for the first two expressions, Actual and Target revenue.  However, for the third expression (Actual vs Target) calculation, instead of using the Sum() function we reference the earlier two results by their expression label names. My impression was that this might calculate faster, because for the last expression QlikView does not need to calculate the sums of the actual and target revenue again. Instead it can use the results that were calculated in the other two expressions:
  • Actual revenue: sum(Actual)
  • Target revenue: sum(Target)
  • Actual vs Target: [Actual revenue] / [Target revenue]
• Variables: Instead of using direct expressions, this option uses variables to store the calculations. I suspected that this method might be a little bit slower, as QlikView would also have to perform Dollar-sign expansion:
  • Actual revenue: $(vActual)
  • Target revenue: $(vTarget)
  • Actual vs Target: $(vAT)

The first test

My initial idea was to create three copies of the pivot table, each containing a different calculation option. After making a selection, I would check the CalcTime for each of the pivot tables via the Objects tab in the Sheet properties dialog.

There was a problem however. It looks as if the CalcTime is not showing the individual calculation time for an object, but rather the cumulative calculation time when the object finished updating. So the first pivot table to be calculated would show a calculation time of 30 seconds, while the second would show 60 seconds. It would actually not take 60 seconds for the second table, but since it had to wait until the first table was calculated that time was being added as well.

The second test

As the three-in-one approach was not going to work, I decided to create three identical applications with only the calculations being different.

I then proceeded to make the same 25 selections (in the same order) in each of the three applications. Afterwards I exported the memory statistics via the General tab in the Document Properties dialog.

This function exports a text file containing memory usage statistics for the various parts of the QlikView document. These .mem files can then be loaded and analyzed in the QlikView Optimizer application. This application originally came with the training materials for QlikView 8.5, but is still compatible with version 10. You can download it by clicking here.

As you can see in the result above, the direct expression has the lowest average calculation time. The variable ends in second place. Label referencing turned out to be the slowest option, which surprised me. Overall the difference between the fastest and slowest option was 0.33%.

Conclusion

So, what did I learn? Well, my suspicion that using variables instead of direct expressions impacts calculation time seems to be confirmed. However, the difference is so small that the it is virtually unnoticeable to the user. I was surprised that label referencing turned out to be the slowest option. Although at 0.33% slower, this is hardly a problem.

While I did not gain any shocking insights from this experiment, it is nice to know that performance is not an issue when picking which option to use. You are free to pick the option that best fits the situation.

For those of you interested in generating random data, here is the script I used.

Download the data generation script

As always, if you have any comments, questions or critiques on the unscientific method I used , feel free to drop them in the comments below.

Starting an expression with or without an equals sign may almost seem like an arbitrary decision. Most developers quickly figure out that this is not true for text objects. However, there is another, less obvious area where the use of the equals sign can greatly impact how (and more importantly, when) your expression is calculated.

When creating a variable in the variable overview (Ctrl + Alt + V) an expression that starts with an equals sign is directly calculated by QlikView. An expression that does not start with an equals sign is not calculated. The implication of this difference becomes clear when you consider the following example:

An application contains data on yearly revenue per store. The raw data is shown above. To get the total revenue, a variable called v_Revenue is created than contains the following expression:

=sum(Revenue)

When this variable is used in a straight table to display the total sum of revenue per store for all years, the following result is shown:

This is obviously not the correct amount, it is the total revenue for all stores and years. Because the variable expression started with an equals sign, it was immediately calculated at the document level by QlikView, without taking the Store dimension into consideration.

The solution is to remove the equals sign from the start of the variable expression:

sum(Revenue)

The next step is to modify the expression in the straight table so that the variable is enclosed in a Dollar-sign followed by parentheses:

$(v_Revenue)

This is called “Dollar-sign expansion” and it tells QlikView to calculate the variable. Because the variable is now being calculated at the straight table expression level, it correctly takes the Store dimension into consideration.

The example QVW below shows the difference between the two variable expressions. As always, if you have questions or comments, feel free to drop them in the comment section below.

Download the example QVW

A few years ago I was the technical lead on a project that required the development of multiple Excel dashboards. I designed and developed (together with Nico Wuite, who did a lot of the coding) an Excel plug-in that could be used to generate stand-alone, fully interactive Excel dashboards. I recently rediscovered the plugin after cleaning up my archive of Excel and VBA reference files and thought it would be fun to generate a demo dashboard.

Have a look at the embedded video below (preferably in full screen HD) and see if it reminds you of a certain BI tool Also, keep in mind that this was built before PowerPivot was released, so it is a little dated by now.

Table of contents

• The story so far
• The new requirements
• Just load the table
• The JOIN prefix
• Join types
• Downloads

The story so far

In the previous post we discussed the example of a paper company that wanted to merge the employee list of their Sales Department of one of their branches (the Stamford branch) into the employee list of another branch office (the Scranton branch). We merged the two tables by using the CONCATENATE prefix, demonstrating the difference between implicit and explicit concatenation along the way. The resulting table is shown on the right.

The new requirements

Now that we have a single, merged Employee table, the manager of the Scranton branch comes up with an additional requirement; wouldn’t it be a cool idea if we could link corporate’s HR data with the merged employee table so we also have everyone’s job description and pay scale available in our reports and dashboards? While I personally reserve the “cool idea” qualification for ideas that are really, well, cool (say, shark cage diving or designing your own heart valve implant) for the sake of this post lets assume that this is a cool idea and that we really want to implement it. So how do we proceed?

Just load the table

The first option we could consider is just loading the table as-is. The resulting data model would look like the picture on the right. Technically, there is nothing wrong with using this approach but I prefer to merge the tables for two reasons:

• It makes for a simpler, less-cluttered data model;
• Logically, it makes more sense for employee-related data to be grouped together into a single employee dimension table.

To merge the columns from two (or more) tables we can use the JOIN prefix.

The JOIN prefix

When the JOIN prefix is put in front of a LOAD statement, it tells QlikView not to load the data into a new table, but instead join the data to a previously loaded table.

The join is a natural join made over all the common fields. This means that QlikView compares all the common fields between the two tables and joins the rows from both tables when the values in the shared columns match.

Optionally, the name of the table to which the data should be joined can be specified between parentheses. If no table name is specified, QlikView assumes that the data should be joined with the last loaded table. Those who read the first post know that I am not a big fan of making assumptions in the load script, it makes the code harder to read and maintain. Therefore I always specify a table name.

Join types

When you look closely at the two tables that we want to join, you notice that not all Person ID’s correspond between the tables. The Employees tables contain an employee, Michael Scott, who is not present in the HR Data table. Conversely, the HR Data table contain data for a Receptionist who is not present in the Employees table.

When we do a standard join, the tables are merged so that the corresponding records from both tables are shown on the same row. Records without a corresponding record in the other table get null (empty) values for those columns. The result is the following table:

This is almost the merged table we want, but it still contains data for a Receptionist who is not an employee at the Scranton branch. Fortunately there is a way to solve this, by specifying the join type.

By using a join type we can specify how QlikView joins the tables, we can use the following options:

• INNER: Only records which are present in both tables are included in the merged table. In our example this would mean that both Person ID 1 (Michael Scott) and 10 (Receptionist) would be excluded from the merged table.
• OUTER: All records from both tables are included in the merged table, regardless if they have corresponding records in the other table. This returns the same result as the standard join.
• LEFT: All records from the first table are included in the merged table, and only those records from the second table which have a corresponding value in the first table. In our example this would mean that Person ID 1 (Michael Scott) would be included and that Person ID 10 (Receptionist) would be excluded, as it has no corresponding value in the first table.
• RIGHT: All records from the second table are included in the merged table, and only those records from the first table which have a corresponding value in the second table. In our example this would mean that Person ID 10 (Receptionist) would be included and that Person ID 1 (Michael Scott) would be excluded, as it has no corresponding value in the second table.

As we want to keep the entire Employee table and only add the corresponding values from the HR Data table to it, we decide to use the LEFT JOIN prefix.

This results in the following merged table:

And that’s how it’s done! The example QVW for this post shows the completed script and also shows what result you get when you use another join type. As always, if you have any questions or comments, feel free to drop them in the comments section.

Downloads

Download the example QVW and source data