Discussion Board for collaboration related to QlikView Deployment.
Installing the lastest version OLE DB driver for Microsoft Visual FoxPro did the trick. Still facing lots of deadlocks but i'll see if scheduling it to off-peak hours can resolve the problem.
Thanks everybody for the support!
if i do execute a reload manually from the QVDesktop, It works without a problem (45 min. to complete). Same qvw. executed in the QVS, takes extremely long and abort with the following error after 3(!) hours:
4-3-2012 06:13:30.4094547 Information Slowing down logging. LoggingSeconds=300
4-3-2012 06:13:30.4094547 Information Reloading
4-3-2012 06:18:30.4267347 Information Reloading.
4-3-2012 06:23:30.4440147 Information Reloading..
4-3-2012 06:28:30.4612947 Information Reloading...
4-3-2012 06:33:30.4785747 Information Reloading....
4-3-2012 06:38:30.4958547 Information Reloading.....
4-3-2012 06:43:30.5131347 Information Reloading......
4-3-2012 06:48:30.5304147 Information Reloading.......
4-3-2012 06:53:30.5476947 Information Reloading........
4-3-2012 06:58:30.5649747 Information Reloading.........
4-3-2012 07:03:30.5822547 Information Reloading..........
4-3-2012 07:08:30.5995347 Information Slowing down logging. LoggingSeconds=600
4-3-2012 07:08:30.5995347 Information Reloading
4-3-2012 07:18:30.6340947 Information Reloading.
4-3-2012 07:28:30.6686547 Information Reloading..
4-3-2012 07:38:30.7032147 Information Reloading...
4-3-2012 07:48:30.7377747 Information Reloading....
4-3-2012 07:58:30.7723347 Information Reloading.....
4-3-2012 08:08:30.8068947 Information Reloading......
4-3-2012 08:18:30.8414547 Information Reloading.......
4-3-2012 08:28:30.8760147 Information Reloading........
4-3-2012 08:38:30.9105747 Information Reloading.........
4-3-2012 08:48:30.9451347 Information Reloading..........
4-3-2012 08:58:30.9796947 Information Slowing down logging. LoggingSeconds=900
4-3-2012 08:58:30.9796947 Information Reloading
4-3-2012 09:00:00.9848787 Error Aborting Reload. Error=QDSMain.TaskResult
4-3-2012 09:00:10.9698288 Warning The QlikView Engine is Reloading, it will be killed (Please ignore logged warnings/errors about the kill).
4-3-2012 09:00:10.9698288 Information Killing the QlikView Engine. ProcessID=7188
4-3-2012 09:00:11.0010806 Information Reload was aborted.
4-3-2012 09:00:11.0010806 Information Initializing Reload (0), Initializing (10802985), Finished (10803016)
4-3-2012 09:00:11.2510950 Information Closed the QlikView Engine successfully. ProcessID=7188
4-3-2012 09:00:11.2510950 Information Finished (0)
Any idea's what could it be?
In QEMC, you can set a timeout at the same window where you config the reload schedule.
You can get more details of your reload job in the log of the reload.
You need to open your qvw in QV Desktop and enable it on Menu settings -> Document properties -> general tab -> Check 'Generate log file'.
After a reload, a file with the same name of your .qvw but with the extesion .log will be generated.
Then, you can post this log here.
If you have a publisher license, as Eric says, you can set the timeout when you configure the reload, you can try setting it to 0 or to the largest number allowed.
If you don't have publisher I believe there is no setting you can change to allow that.
If you don't mind me asking, why do you need a task that long? perhaps you should look into splitting it into smaller tasks, or making the process more efficient.
Unfortunatly we don't posses a publisher license.
Why it's taking so long is a part of the problem. If I manually run reload (Ctrl+R) from Qlikview Desktop, it successfully complete a reload with less than 20 minutes. Same reload within the QVS takes over 3 hours and bails with error. somewhere along the line it just hangs...
The script is using OLE DB connection to reccursuvly open 60 FoxPro databases located on file system. The account running the QVS has read rights on the designated folders.
I read it forum that there is a performance decrease in QV 10 SR3.
I had faced memory issue in my application with QV 10 SR3 and installing QV 10 SR4 resolved it.
I think this might be a similar case.
Test it in different machine with SR4 and see if there is an difference
Upgrading to the latest SR might be beneficial if as Deepak says there is an identified performance decrease, but before doing this have you tried breaking the qvw up by loading, say, only the first 20 files? Then if OK increase by another 20, etc, etc. One of your source files may be the cause.
Are the files in a live environment and being accessed at the same time as you are accessing them?
Upgrading to the latest SR may be beneficial if a performance issue has been identified with SR3 as Deepak says, however have you tried breaking up the load to see if one of the source files is the reason? I would try loading 10 files and if okay then increase to 20 etc, just to prove this isn't the cause.
Are these source files being updated from a live environment?
yes. source files are indeed being updated in live environment. Deadlocks was my first theory. However, if i do a reload through the Qlikview desktop it works fine. In both cases, same credentials are being used. For some reason the qvs just hangs and stop with an error when it reach timeout. qvconnect32.exe instance is left open.
How come it works on the QV Desktop but not in the QVS? Are they using the same engine?
Problem persist after upgrading to SR4.
I've tried to run again the .qvw from the QV Desktop using the same account as the QVS. The account has read-access on the file directory. This is incredinbly slow. the qvconnect instance goes up to 50% CPU and 285K memory an eventually hangs.
Using the same approach but now using account with domain's administrator role - work just fine.
I know it's bad practice to use the same account as of the QVS service but I had to use an account which has read access on the folder.