Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I have a VBS script that opens all QVW's in a folder and then writes them to a backup folder without data. This script works flawlessly both in VbsEdit and via the command prompt. Every QVW, with or without section access, is opened and written neatly.
For this I use this code:
targetFile = "C:\QlikView\Test.QVW"
strPath = FSO.GetAbsolutePathName(targetFile)
Set MyApp = CreateObject("QlikTech.QlikView")
Set MyDoc = MyApp.OpenDocEx(strPath, 0, False, , , , True)
If I now run the script via the Windows Tasksscheduler, the script only works for the QVWs without section access. Processes that run via the Windows Tasksscheduler are not run in a user session but in "Session 0".
QlikView Desktop then does not recognize the user and cannot find the license (license lease). For this I already use PSExec :
C:\PSTools\psexec \\QlikServer -u QlikAdmin -p 1234 C:\QlikView\Backup_All.cmd
Thanks to PSExec, the script runs, but it hangs when a QVW with section access is loaded. I have already tested with passing credentials but that makes no difference :
Set MyDoc = MyApp.OpenDocEx(strPath, 0, False, "QlikAdmin", "12345", , True)
What could be the reason that QVWs with section access do not want to be opened? What is the solution for this?
Can you describe what the hang looks like? If it's waiting for interactive input, there may be an entry in the windows Event Log.
Does the psexec method complete or hang if you run it from a cmd prompt?
-Rob
Hi Rob,
I'm having a write to log command before the OpenDocEx and after the OpenDocEx. The log ends with the start of the OpenDocEx command :
No entry in the Windows Event Viewer. See Task manager screenshot in OT : QV.exe loads the app in memory and halts then with the document in memory. No CPU or memory activity anymore for the QV.exe process.
The psexec is working fine when run from a cmd prompt :
Sander
We have a similar job for a backup of the applications but we don't execute it within an automated task else execute it manually in a irregularly period of time. But we do a lot of export & print jobs within automated tasks without a logged user. Mostly the qmc triggers a reload with an EXECUTE statement which triggers a windows-tasks which runs the desktop client with a control-application which then runs through a variety of applications and doing there multiple exports/prints + e-mailing them.
Important for it is that the windows-tasks runs with the right user (the services-user with admin-rights) and with the highest privileges but no logged in user. Further the following settings are needed:
The applications are with and without section access and the service-user is of course listed there as admin. The section access used only NTNAME and no USER / PASSWORD. For us it worked smoothly ...
- Marcus
Can you try with the -i switch in PsExec?
-Rob
Hi @marcus_sommer ,
Thank you for your detailed response. What I still don't get from your response is how you make backups of QVWs. Because I want to save the QVW's without data, I work with a VBS script. Do you also store the QVWs without data and also using a VBS script?
Starting the process through an EXECUTE from QlikView Desktop works. However, if I run the QVW with the execute via the QMC, this also doesn't work. A QVB process is started, which then no longer has any activity.
Your advise for the settings :
Any other thoughts?
Thanks,
Sander
Hi @rwunderlich ,
I already tried the -i option : "psexec -i 0 \\Servername ..... "
No result 😞
Thanx,
Sander
Hi @marcus_sommer ,
Thank you for your detailed response. What I still don't get from your response is how you make backups of QVWs. Because I want to save the QVW's without data, I work with a VBS script. Do you also store the QVWs without data and also using a VBS script?
Starting the process through an EXECUTE from QlikView Desktop works. However, if I run the QVW with the execute via the QMC, this also doesn't work. A QVB process is started, which then no longer has any activity.
Your advise for the settings :
Settings.ini from server --> AllowExecuteCommand=1
> Added this setting to the ini
Settings.ini vom DistributionService --> AllowExecuteCommand=1
> This .ini is probably from Publisher? We don't have a Publisher license
QVdistributionservice.exe.
> Changed this setting to true
adding the user to "Log on as batch job"
--> secpol.msc --> Security Settings --> Local Policies --> User Rights Assignment node
--> open "Log on as batch job" --> Add user
> User account is member of the local administrators group, administrators group is already member of this "Log on as batch job" option.
Any other thoughts?
Thanks,
Sander
We don't use an open without data else open the applications regularly and apply then a selection on the current/last period/date and then a ReduceData-statement and afterwards a SaveAs-Statement to special folder with an included timestamp. Unless the smaller applications with any dimensions-data which have just a few MB.
That's performed from a control-application in which we could chose which applications should be again secured within the backup. This is manually triggered after essential changes on certain applications or all few weeks for everything. This fulfilled our requirements and therefore we don't use automated tasks on it.
The control-application itself is controlled from external excel-files which contains multiple meta-data for all applications, for example the load-mode (full, partial, incremental, incremental+), partial-periods, the needed reducing-field for the selection and some more information - used for qmc-tasks as well as for manually batch-reloading.
But in regard to your issue we do quite the same with our print- and export-jobs which is opening applications with and without section access and doing then anything. All actions are done with VBS - which runs internally within the desktop client whereby we use always specialized control-applications which loop through internal tables to get the relevant information like path, filename, report-id, mailing-lists and so on.
We have also no publisher but I wasn't quite correct by the settings.ini from the distribution - the file which was meant is here:
C:\Windows\System32\config\systemprofile\AppData\Roaming\QlikTech\QlikViewBatch\Settings.ini
I'm not sure if it's always enough that a user is a member of a certain group - for example the local administrators and has therefore automatically all needed access rights to a storage which has the administrators as permitted users. Recently I struggled a few times in which I couldn't access and/or write/change files although it looked that my admin-user had already those access-rights - but it didn't worked. I could only access after I added my admin-user manually and give him the needed rights. Therefore just to be sure go manually to the folders and try to add any dummy-files and also to change and to delete them (an experienced admin may check these on other ways ...).
- Marcus