Qlik Community

QlikView Documents

Documents for QlikView related information.

Announcements
QlikView Fans! We’d love to hear from you.
Share your QlikView feedback with the product team… Click here to participate in our 5-minute survey.
Rules, plus terms and conditions, can be found here.

FAST-LANE-DEVELOPING - for when time (otherwise spent waiting for a QV_script to reload) is an issue

datanibbler
Esteemed Contributor

FAST-LANE-DEVELOPING - for when time (otherwise spent waiting for a QV_script to reload) is an issue

Hi folks,

I found this (honour to whom it is due, I found it in a "Best_practices_guide" or some other document here, I don't remember too clearly).


Just thought I'd share this and make it more prominent as I really think this should be a MUST KNOW for developers, even for newbies as it isn't hard and saves you significant time.


So let's go.

=> Background:
- Suppose I have two directories:
     - One where I have the "live" apps that can be used by my users (I'll call it Dir_A)
     - One for myself and the developers that users can't access (I'll call it Dir_B)
- What I do routinely is, I open the app in Dir_A, save it ("save as") in Dir_B, work on it, test it and then save it back ("save as") in 
   Dir_A => all the licenses stay since the name is the same
- My apps all have an "EXIT" tab with only one command "EXIT SCRIPT"
- Many of my apps have a hidden script with either a section_access or an ODBC_connect_string or so

=> What I do now is:
- I start off by opening the "live" App (that I know is up-to-date and working) in Dir_A
- I save that ("save as") in Dir_B, so now I have an exact copy
- Then, to not confuse myself, I rename the "EXIT" tab in the scipt to "EXIT_original" and make a new one that I can move around.
- Then, since the hidden_script is ALWAYS the leftmost one (I can't move that one), I cannot make a new tab left of it
   => so I have to open that and use it
- In the hidden_script, I deactivate the connect_string or whatever there is (just comment it, don't delete)
   and, ABOVE that, I insert a BINARY LOAD (use the wizard) pointing to the "live" app in Dir_A

- Now, upon reload (don't reload yet), all the data is loaded EXTREMELY FAST from the app in Dir_A
   => I have to move the new "EXIT" tab directly to the right of "Main" or so, so that all the regular LOADs are inactive
  <=> I might have to move one tab to the left of the new "EXIT" in case I need a table that I have a DROP for in the "live" app

    => now save (still in Dir_B) and reload (can be done locally)


=>=> That's it really. Try it out, the BINARY LOAD is extremely fast (as compared to a LOAD from a qvd or even more from Excel)
             and, since all the data is there, all the existing charts in the app (always in Dir_B) should work.
             => I haven't measured it and it depends on your "was_state" to compare with - but the time_saving in any case is
                   SIGNIFICANT.

- Just remember, after developing (BEFORE you copy that back into your Dir_A) to
     - deactivate the BINARY LOAD
     - re-activate the connect_string or whatever there was in the hidden_script (I suppose it's required)
     - move the new "EXIT" tab out of the way, behind the "EXIT_original"
     - Test it

Best regards,

DataNibbler

Tags (2)
Comments
vadimtsushko
Contributor III

Well. I would argue that end user application should use binary load from datamart anyway. Both in production and developing mode.

It is very useful to separate work and responsibility between ETL jobs and visualization. 

datanibbler
Esteemed Contributor

Hi Vadim,

thanks for your comment!

=> Yes, you're right, apps should always use a BINARY LOAD from a datamart - IF POSSIBLE
<=> it is not always possible (well, sometimes it would be possible, but there would be no point to reload the
       datamart every 3hrs and then BINARY load the app instead of just reloading the app all 3hrs - no or very
       little time saved)

Second point: Yes, it would be very advisable to separate those two jobs - but unfortunately that is seldom the employee's (that would be, your) decision ;-)

flipside
Valued Contributor II

Hi DataNibbler,

I haven't fully read (or perhaps understood) what you're trying to do, but you may be missing a trick.

Why not have an include statement as your first line to read in the binary command followed by an exit command. If the file being loaded in doesn't exist, then the binary and exit commands don't execute and the script will load whatever follows. Seems you wouldn't need to go through all the script manipulation each time.

What I tend to do is name the 'include' referenced file the same as the .qvw with a config extension so I know what it relates to.

flipside

EDIT: Here's a way to test it ...

1) Create a new qv app called BinarySource.qvw and load script is ...

Load * inline [
Comment
This data comes via a binary load
]
;

2) Create a second qv app called BinaryLoad.qvw and load script is ...

$(include=BinaryLoad.config) ;
Data:
Load * inline [
Comment
You are loading data inline - is your config file missing!
]
;

Of course the include statement will need to be the very first line for binary to work.

3) Create a config file called BinaryLoad.config in the same folder as the .qvw ...

Binary [BinarySource.qvw];

exit script;

Now test it by running it and run again after changing the config file to, say, BinaryLoad2.config.

flipside

datanibbler
Esteemed Contributor


Hi flipside,

excellent. I'm not sure that would work in my instance: Since I usually have to versions of the same app, both with the same name (one in Dir_A, one in Dir_B, the app that the BINARY points to would ALWAYS exist - but if I have the app in Dir_A open and the BINARY points to just that, I would expect that it would not execute)

You do have a point, however. That would certainly save time.

Best regards,

DataNibbler

vadimtsushko
Contributor III

Hi DataNibbler

I believe flipside's recipe should work in your scenario too (I use similar technique for other purposes).

Suppose you have same application App.qvw in Dir_A and Dir_B. In that application you have $(include=App.qvs) as first line directive. App.qvs does not exists in Dir_A so for application in Dir_A that directive do nothing.

App.qvs does exists in Dir_A and consist of lines

Binary  [..\Dir_A\App.qvw];

exit script;

So in Dir_B same application just do binary load and exit script. Bingo.


datanibbler
Esteemed Contributor

Hi all,

now I have a question on this myself that I haven't thought about before - or maybe I just overlooked something or the timing of reloading the different versions of the app was bad ...

Anyway: What about variables (colour_palette) coming from a qvs file? Are they inherited in a BINARY LOAD? (I have actually added a new colour in my qvs file and reloaded the "live" app (that the Dev_BINARY points to), but I spent some time searching in vain for that colour_variable in the "working" app.

Can anyone enlighten me on this one?

Thanks a lot!

Best regards,

DataNibbler

vadimtsushko
Contributor III

Hi, DataNibbler.

According to my experience binary load do not transfer variables from datamart. And in my opinion it is a good thing. It is one more aspect of separating ETL part of whole project from visualization part.

For example without any efforts your user application is reliably shielded from any variables leaked from ETL scripts.

In that approach user applcation load script consist of binary load from datamart, part loading variables used in chart expressions from external storage and part loading some configuration data used in visualization.

datanibbler
Esteemed Contributor

Hi Vadim,

I believe you're right, QV probably doesn't transfer those.

Well, in this approach, I would like to do so, it would make the selection of what to (de-)activate in the script when using that DEV_BINARY easier - but ok. Overwriting the ?existing? variables by keeping the Include_statements active is not a big thing.

Thanks a lot!

Best regards,

DataNibbler

vadimtsushko
Contributor III

Overwriting the ?existing? variables by keeping the Include_statements active is not a big thing.

I'm curious about that. Obviously if you are keeping your variables externally you overwrite existing variables (previously loaded from same external storage too) every time on reload. That is normal workflow.

Do you mean some other problem, say DEV to PRODUCTION relationship?

If you are using relative path to access your variables storage from application then you can develop and change your variables in DEV directory then after testing simply copy application and variable storage to PRODUCTION directory. It should work.

Do you have some problem with that approach?

datanibbler
Esteemed Contributor

Hi,

there is no problem. I just didn't know that was normal expected behaviour.

I am using a (relative path, so Dir_A or Dir_B doesn't matter) to a qvs where the definitions of my colour_variables are stored.

These are loaded via an Include_statement in the "live" app in Dir_A. When the "WIP" app in Dir_B loads BINARY from the "live" one, the variables are obviously not loaded from that one. That would be practical in this case, but never mind. I just keep the Include_statements active in the "WIP" app.

Best regards,

DataNibbler

Version history
Revision #:
1 of 1
Last update:
‎04-04-2014 02:55 AM
Updated by: