Turn on the Generate Logfile checkbox under Settings > Document Properties. If it's something in the QlikView document not loading properly, that logfile will show it. It gets generated in the same folder as the QlikView document each time the script runs.
Hi, thanks for your answer, there is no problem with the script when I reload from the document.
I get the errors when loading from the publisher at 7:00 in the morning, I'd like to know if it's a QV problem or a DB acces for example, the script itself is OK, it seems something kills the QV engine while reloading, but what...
Just remember, the reload runs under the credentials of the account running the Execution Service and if this account does not have privileges for the DB for example this is where you might be stuck. If you are logged in with another account when running the reload through developer you run the load on different premises with different credentials.
Easiest way to check is to log on as the user set to run the service and do a manual reload, or turn on the generate log file checkbox.
Well, I didn't mention that the reload from publisher was working fine for a long time, it starts having errors yesterday and today again.
The log file attached mention message :
The QlikView Engine working with document "E:\Maquette QlikTech\Applications\Ulyss\AvancementRepartition.qvw" hasn't been responding for 1800 seconds. It will be killed.
It appears 10 mns after the reload starts, the reload takes 40 mns
We had that symptom with a large document that, due to some insufficient settings on our server, started swapping to disk while there was still plenty of physical RAM available. You pretty much never want QlikView to have to swap anything to disk. In addition to being inefficient, it just tends to crash in my experience. Like you, it would run fine if I reloaded manually, I suspect because there wasn't as much going on at the time, so more memory was available. So one possibility is that you have insufficient memory for the reload, or aren't set up properly to take advantage of available memory.
I'm sure there are plenty of other possibilities. That's just the one we ran into.
