Skip to main content
Do More with Qlik - Qlik Cloud Analytics Recap and Getting Started, June 19: REGISTER
Showing results for 
Search instead for 
Did you mean: 

Query timeout parameter


while fetching data from an Excel per ODBC may occur various errors. To avoid a load-error I use the ERRORMODE feature to detect and react on the specific error-code to skip or to repeat the query and doing some more things. This worked principally but the time-span between the error and the next statement varies significantly and without a clear pattern. Mostly by around 15 minutes but also 3 minutes and nearly an hour were already noticed.

This means the behaviour differs between a manual reaction on the error - just clicking on ok. by any error instead of canceling the execution - and the next statement runs immediately. By using the ERRORMODE QlikView or the connection waits for anything - probably any kind of another timeout - before going further.

Used is the standard MS ODBC driver package from the Office installation with a connection-string like:

ODBC CONNECT32 TO [Excel Files;DBQ=$(file)];

Could anyone shed some light what and why it happens in this way and how to solve or bypass the issue? Means are there any settings on the Qlik side and/or inside the various registry-keys for the ODBC drivers and/or could it specified with further parameters within the connection-string?  Any ideas?

Many thanks,

Labels (2)
2 Replies

All I can think for now is what else is going on between QlikView and the source file? I.e.: is there a high, unexpected spike in network activity? Is that true if the QVW only has the CONNECT statement or when loading from it?

Finally, it shows as ODBC 32, are there any differences if you use ODBC 64 instead?


I'm quite sure that the issue isn't related to the network. The files are quite small with approximately 3 MB and source and target are within a 10 gigabit network and even by a higher workload the transferring of the data worked smoothly.

The origin load-logic is quite old and runs since years. Errors were here rarely and therefore none additionally logic to handle them. Since about two weeks the errors became randomly and therefore the ERRORMODE to avoid the script-error. By multiple manually attempts to check the error-logic - which runs within an additionally loop to repeat the failed load n times after waiting n seconds and tracking the errors within a special error-table - I noticed the mentioned delays without a clear pattern. If I now look on the logs and the error-table which were created by a qmc-tasks it worked like it should. No extra waiting times else after the sql-error it branched immediately to the else part.

This means anything is different between the QV desktop client and the server. Both are running with the same release 12.5 SR3 and also the odbc-driver are exactly the same. Different were the users and the settings.ini aren't identically whereby I didn't noticed any setting which may be related to such a behaviour. Something is different but what? Are there any differences between the qvb.exe and the qv.exe by reloading an application (unless the not loaded UI by the qvb.exe and maybe some differences in regard to the logging)?

- Marcus