Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Note: This issue may have occurred in earlier releases of QlikView 12.
I have a use case where I use a Windows batch file and Qlikview desktop client to reload a document. This used to work great in Qlikview 11.20 but is now broken badly. The command line is:
"C:\Program Files\QlikView\Qv.exe" /r MyDoc.qvw /vFlag=1 /vAnotherFlag=3
This is supposed to reload MyDoc.qvw and pass it two variables Flag and AnotherFlag with certain values. It worked great in QlikView 11.20
In Qlikview 12, the above command line opens the document and saves it WITHOUT EXECUTING THE SCRIPT! The log file ends like this:
2018-05-03 13:48:11 ScriptMode Legacy (gives greater system access) (aka qv11 mode)
2018-05-03 13:48:11 SequentialThreadCount 29
2018-05-03 13:48:11 NumberOfCores (effective) 8
2018-05-03 13:48:11 ReloadCodebase Bnf
2018-05-03 13:48:11 Reload Executed By MyDomain\MyAccount
2018-05-03 13:48:11 Process Executing QlikView Desktop
2018-05-03 13:48:11 Process ID 4408
2018-05-03 13:48:11 Execution finished.
No actual work is performed!
Through trial and error, I found that using the NoData switch would cause the reload to occur properly
"C:\Program Files\QlikView\Qv.exe" /NoData /r MyDoc.qvw /vFlag=1 /vAnotherFlag=3
BUT: From the QlikView help file: https://help.qlik.com/en-US/qlikview/November2017/Subsystems/Client/Content/Starting_QlikView.htm
When /v is used together with /nodata, the variable will keep its current value and will not obtain the assigned value.
So there appears to be no way to reload a document AND pass it variable values.
This is a big undocumented bug and really should be fixed. Also, there is no reason to mix up the /nodata and /v switches. They do different things completely and all combinations should be supported.
If anyone can provide any workarounds to reload a document AND pass it variable values, I will greatly appreciate it.
If it's broken, then I don't think there will be a solution or workaround using just command-line switches. IMHO you should submit a case with Qlik Support to get the reasoning behind this behavior (if it's not considered a bug, indeed "fear the WAD-demon" )
If you have some some flexibility, then in your batch file you could store your variables in a txt/csv file and load them in your script. If the file doesn't exist, you could rely on default values or previous values to make this an operation for special circumstances. Until the bug gets fixed.
Peter
Actually I don't use QlikView 12 and have therefore no own experience of the various changes in regard to the executing of tasks and AFAIK there were some changes to default settings and a few new features which all needs to be configured properly. Also I remember of reading that in BNF are bugs. Here some links which could be a starting point to find the relevant settings:
Authorizing the Script EXECUTE Statement | Qlikview Cookbook
Re: Bug! Quickly! QlikView November 2017 SR1 and SR2 and SR3. Tell the developers!
An alternatively to the command-line could be to use vbs to update your applications, for example:
Re: Vbs - passing parameters to opendoc or opendocex
- Marcus
Hi Kevin,
I have tested this in 12.20 SR4 and I find no issue.
"C:\Program Files\QlikView\qv.exe" /r c:\test.qvw /vMY_VARIABLE=bbt will open the doucment and set MY_VARIABLEt to bbt and reload the data.
according to the manual /nodata Opens the document without variables so, it doesn't set the variable
/nodata
Opens the document without variables, table and field data. This feature is also available for previously
opened documents on The Start Page (page 41).
Bill
Hi Bill,
I am able to reproduce the problem that the /r flag does not actually reload the script.
I have attached MyDoc.qvw and MyDoc.qvw.log The command line I used was:
"C:\Program Files\QlikView\Qv.exe" /r MyDoc.qvw
On my system, the document is opened and saved without actually reloading the script. None of the trace statements or the sleep statement are executed. I've attached the log file too.
Does this happens only with this application or with all ones (maybe creating a new one just for testing)? Is there are any difference between a manually execution of the batch to a from the qmc, windows tasks or any other tool triggered execution?
If I look within the document settings there are two settings which might have an impact on this topic and this are within the document properties in tab security the last option of no restrictions for the admin and within the script-editor these settings:
Further you might get some hints to the issue by looking in the windows event-logs and enabling the ExtendErrorLoggingMode in the easter egg.
- Marcus
Hi kevin,
It is working fine for me. Attached are the two log files. One where I ran with /r and the other is manually.
Also, wanted to add, I did more digging and found a bug put in on this way back in version 9. The bug was closed as "working as Designed". The reason given was "Variables are stored as Data - hence opening without data removes the variables"
Their workaround was to set the variables in the script.
Bill
By comparing the log-files I see a difference in the option of "BackupBeforeReload" - maybe this user-setting breaks it.
- Marcus
Thanks, Bill and Marcus for your help!
The User Preference Save > Save Before Reload seems to play a key role. If it is checked, then the reload does not occur. If it is NOT checked, the reload occurs normally and the script is executed.
This of course does not make any sense, but the behavior is consistent.
So the full command line below works properly provided that Save > Save Before Reload is not checked. The script is executed and the variables values are set properly to what was specified on the command line.
"C:\Program Files\QlikView\Qv.exe" /r MyDoc.qvw /vFlag=1 /vAnotherFlag=3
Glad you found out what is triggering this anomaly. Nice work! I would assume that with Save-Before-Reload enabled, one would get two saves instead of a single one that moves from last place to first place...
Can you post a case with Qlik Support? I figure that with your detailed analysis it will go straight to R&D and they will respond with either a bug ID or a "Working-As-Designed". In the first case, you may get a fix within the next few releases. In the second case you get an explanation about why this is happening.