Qlik Community

QlikView Administration

Discussion Board for collaboration on QlikView Management.

Announcements
Read about the latest Qlik Community enhancements on the Community News blog!
cancel
Showing results for 
Search instead for 
Did you mean: 
tobiasstrobel
Partner
Partner

QV automated Reload stops

Hi everybody,

i have a problem at one of my customers.

This customer has an automation software (automic) which runs all reload + publish jobs.

All of them are working correctly, except one. This Reload is stopping at the exact same position every time.

The Reload gets triggered by the following command:

C:\Program Files\QlikView\qv.exe /R "Filepath"

When i run the Reload manually, everything works as expected, same when i run the command, run it via powershell or a Task in TaskSheduler. But here i noticed the follwing. The task only runs when i select "Run only when user is logged on". When i select "run whether user is logged on or not", the reload is stopping at the same point as it does with the automation software.

Does anybody have ideas to this case?

 

4 Replies
Chip_Matejowsky
Support
Support

Hi @tobiasstrobel,

Based upon your description, sounds as if there's a permissions issue going on.

Do you have document logging enabled for the QVW? It should have some information potential errors when the reload fails.  If you don't have document logging enabled, open the QVW in QlikView Desktop, select Settings > Document Properties > General tab and tick both the Generate Logfile and Timestamp in Logfile Name checkboxes.  Click OK, save the QVW and then attempt a reload.  This will generate a log for each reload attempt and the log will be stored in the same directory where the QVW is stored.  

Generate document log.png

If you have questions on what you see in the log, post back here.

Hope this helps

Best Regards

Sr. Technical Support Engineer with Qlik Support
Help users find answers! Don't forget to mark a solution that worked for you!
tobiasstrobel
Partner
Partner
Author

Hi @Chip_Matejowsky ,

thank you very much for your help.

You are right, usually this is helpful, I already checked both of the options you named.

Problem is: the Logfile is only generated, if the Reload is successful or fails with an error, but neither is the case. The Reload is just stopping whichs means neither completing nor failing.

The User, which i am trying to execute the Task is always the same one.

Chip_Matejowsky
Support
Support

@tobiasstrobel,

Ah, okay.  You stated The task only runs when i select "Run only when user is logged on". When i select "run whether user is logged on or not", the reload is stopping at the same point as it does with the automation software, so in this scenario, the task doesn't run if user is not logged on, correct?  If so, then it seems like there could be a connection issue to the source data occurring.

Sr. Technical Support Engineer with Qlik Support
Help users find answers! Don't forget to mark a solution that worked for you!
marcus_sommer
MVP & Luminary
MVP & Luminary

Within the user-properties in tab general is another log-setting to write the log immediately - AFAIK by each load-step and not just after finishing the job which might not happens if the reload failed.

Beside this you may implement an own logging within your application - maybe something very simple, like:

t1:
load tablename(nooftables()) as Table, noofrows(tablename(nooftables())) as Records
autogenerate 1;
store t1 into t1.txt (txt);

and this after the important or maybe all load-statements and you will get much nearer to the point where it breaks and what happens before.


Further important is the understanding that if no user is logged on Windows will take it's own default-user. This user may not have the appropriate access right within the filesystem or to db-connections and/or have proper licences and/or settings for QlikView and other related tools like Excel by any macro-exports or the PDF printer or the mail-client and so on. The smallest request from any of them in an popup like "are your sure that ..." or "commit or cancel the following" or similar stuff will prevent a successful execution.

Some of the above mentioned possibilities could be bypassed by forcing to run the batch with a certain user like with the RUNAS method but it may not work in all scenarios because the availability of certain features/libraries depend on that an user (and the right one) is logged on - means those features/libraries aren't loaded/activated and so early binding accesses will fail unless they are loaded/activated explicitly in a late binding before any access on them happens.

Unfortunately I'm not an expert on such admin-stuff so that I couldn't give more detailed advices but if the logging give not enough information you have some hints what might be further wrong to dig there a bit deeper. 

Maybe Chip_Matejowsky could give here some more hints what are critical points and how to detect them.

- Marcus