Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
We have a Qlikview V10 document which incorporates a post reload trigger that runs a VBSript module to generate a CSV. The reload of this document is scheduled to run weekly on our server but it does not appear to be updating the CSV file.
We are wondering if this is because of the module security part of QV and if this is stopping the macro running as part of a scheduled reload. When we open the document manually and hit reload then we get the normal module security dialog box which once completed does then update the CSV.
Our question is therefore how do we tell the Qlikview server to trust this macro so that it can run during our weekly reload?
Many thanks,
Ross
Hi Ross,
OnPostReload macros don't work in a server - client environment by design, even when they work if you do the reload locally, opening the document with the Desktop version of QlikView. The macro will do work if it's triggered from the Plugin client manually, though.
If you want to create those CSV you can do a STORE into text files instead of QVD files.
Hope that helps.
BI Consultant
You could also put the macro code in a OnOpen trigger, and then make the QVW reload via an External Program call (Enterprise Mgmt Console, System, Supporting Tasks, External Programs for the reload server) with a command line call such as
"C:\Program Files\QlikView\qv.exe" /r /vvCreateCSV=1 "E:\QlikView Storage\some_qvw_name.qvw"
If you alsways want to create the CSV file you can skip the vCreateCSV variable above, but sometimes it is useful to be able to control what is done during the reload via an variable like this. If you include vCreateCSV in the call you have to test for it in the macro, using something like
sub ReportCheck
set var = ActiveDocument.Variables("vCreateCSV")
val = var.GetContent.String
if val = 1 then
call Create_CSV
var.SetContent 0, true ' Set create CSV flag to 0
end if
End Sub
A potential downside of using external program calls is that you loose the more fine-grained control of the execution, for example number of retries and timeout (on the trigger pane of the job configuration dialog in Enterprise manager). But that hasn't really been an issue in cases where I've used this approach.
Best,
Göran