Sleep in case of error?

[datanibbler]

Hi,

I've been here with this issue before - it is still happening: When one of our primary data_loading apps runs and, in the normal ccourse of the script_execution, tries to store a table - and in that exact moment, one of the few reports I have around for local execution is being used and is reading that same file => the STORE fails, that's what I can read from the log in every single such case, and the entire data_loading app fails.

What I usually do in those cases is simply that - I manually restart the data_loading app from the QMC and hope that it will run fine the second time. There is no more I can do, there is no practical way of preenting that kind of conflict.

Isn't there a possibility, if that kind of error occurs, to just tell the script to wait a minute or so and then try again to resume script_execution?

Thanks a lot!

Best regards,

DataNibbler

[Peter_Cammaert · Accepted solution]

Yes there is. It's done in the load script but you'll have to code this trick yourself.

For example, this might work:

// The following either succeeds, or ends script execution when all 5 attempts fail

SET ErrorMode = 0;

FOR i = 1 TO 5 // Max 5 attempts

  IF i = 5 THEN

    SET ErrorMode = 1; // or whatever the default mode is

  END IF

  STORE NewTable INTO [NewTableFile.qvd] (qvd);

  IF ScriptError = 0 THEN

    EXIT FOR

  END IF

  SLEEP 60*1000; // 1 minute

NEXT

SET ErrorMode = 1;

Or a variation of this code that better fits your environment. If there are many internal tables that should get this treatment, put the code in a SUB with one parameter (Tablename) and CALL the sub where needed.

Best,

Peter

[datanibbler]

Hi Peter,

that looks cool! I'll give it a go.

Thanks a lot!

[datanibbler]

I just checked once more. I have a routine in the script already to check the time that has elapsed since the qvd (well, one of the tables used in the report) was last saved, and if that time is close to the interval for the data_loading app, then I display a MsgBox and exit the script - so the risk of a conflict is only with the other tables and is minimal overall - but it happened just now 😉

Strange - well, strange things happen here, that is totally normal ...