topic Binary Statement Clarification in QlikView

Binary Statement Clarification

Fri, 25 Sep 2009 05:22:37 GMT

I've searched the reference manual and this forum, and there's not much about the Binary statement. Has anyone used it? Why and When would you use it, rather than copying the code into the new project? Does it save memory? Is it faster?

It seems pretty straightforward on how to use it, but can someone give me some explanation on When to use it? And what is the reasoning behind only being able to use it once and at the beginning of the script? Any clarification on this would be much appreciated!

Binary Statement Clarification

biester — Fri, 25 Sep 2009 12:33:37 GMT

Hi,

you cannot reload a .qvw if you don't have the datasources used in the script. But you can binary load from let's say Source.qvw in the Target.qvw and then any time reload the Target.qvw and manipulate data structure there without having to have the data sources. As manual says binary load from qvw is as quick as loading from qvd (hence usually more quick than loading from the data sources). You can also restrict access to Source.qvw and give access only to Target.qvw; thus in the script of the Target.qvw "there is no reference to the original data sources and it will thus reveal nothing about the structure, passwords etc. of the database" (MANUAL!!).
The manual says: "Binary load uses very special logic to read the data already processed once into QlikView in another QlikView document. The "unpacking" used requires a "clean slate" in memory which is the reason why a Binary statement must be the very first statement in the script. Therefore it is also impossible to use Binary more than once in a script. However you can use QVD files to consolidate data from multiple QlikView documents at the same speed as with Binary."

Perhaps that helps,
Rgds,
Joachim

Binary Statement Clarification

johnw — Tue, 29 Sep 2009 07:06:53 GMT

I use binary load in only a single application. I binary load the entire data structure, then drop tables, fields, and field values that are sensitive. Only a few people have access to the original application. Many more people have access to the reduced application. It may now be possible to accomplish the same thing with data reduction, publisher and so on, but since the application has been working for a couple years now with very little current maintenance, I haven't reexamined the issue.

For a while, for development speed, I had used a binary load in another application. This seemed easier in that particular case than creating the needed new QVDs to support the two user applications. But I did go on to create the new QVDs, and change the user applications to load from the new QVDs, rather than having one do a lot of processing, and the other do a binary load. I don't consider that to have been a good use of a binary load, but sometimes the real world forces us into approaches that we would normally avoid.

What I doubt I would ever suggest is "copying the code into a new project". Please don't put yourself (or worse, someone else) in a situation where you must maintain two copies of the exact same code. That's at least a lot of extra trouble, and at worst a disaster in the making. In general, I would suggest putting the common code into a separate application that writes out one or more QVDs used by the two user applications.

Binary Statement Clarification

Mon, 24 May 2010 10:52:04 GMT

It is very useful when developping large models. I use it in a model that takes about 45 min to reload from SQL server, loads in about 12 seconds!

Also useful in version control, if you develop model for use by someone who doesn't have access to the database give them an empty model with binary reload from the file you maintain

Binary Statement Clarification

masselin — Tue, 29 Jun 2010 17:59:38 GMT

Hi,

IT exports monthly qvd files from mainframe. I create qvw application with most important / used data to provide professional users (not entreprise licensed ones) to get quickly (reload time very short) to necessary date for their business requirements. They very often just have a binary line and an excel file in the script. Business applications are thus very simple to develop, understand and maintain.

Additionnal benefit, you can upgrade your data structure and all business application will inherit from the enhancements when reloaded.

My problem is now that I would very much appreciate to find a way to drop records not useful for specific uses in the specific business applications ... as binary load does not come with any where clause. Left keep from resident tables very often turn memory alerts on ([:'(])

Binary Statement Clarification

johnw — Tue, 29 Jun 2010 22:01:20 GMT

I typically use inner joins to reduce my data after the fact. I have so far found them to be very fast and efficient. That should work just fine after a binary load.

So for example, you have every order item you've ever had along with every item that was ordered in a QVW. For a specific business application, you only want the active orders and associated items. Lets say the item specifies the order it is for. You could probably do something like this:

BINARY AllOrdersAndItems.qvw;

INNER JOIN ([Orders])
LOAD 'Active' as Status
AUTOGENERATE 1
;
INNER JOIN ([Items])
LOAD Order
RESIDENT [Orders]
;

Edit: Mind you, I'd instead do this, but that's the QVD way, not the QVW way:

[Orders]:
LOAD 'Active' as Status
AUTOGENERATE 1
;
INNER JOIN ([Orders])
LOAD
fields I care about
FROM Orders.qvd (QVD)
WHERE exists(Status)
;
[Items]:
LOAD
fields I care about
FROM Items.qvd (QVD)
WHERE exists(Order)
;