cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Execution of (scheduled) Scripts

Execution of (scheduled) Scripts

Using scheduled scripts we face the problem that everytime there is an invalid value inside an item, WHOLE script will be stopped.

(Internally there will be done an SQL Rollback to garantuee Data Consistency). For what (content) reasons will this happen?

  • A User has left department/company, thus his ID can't be used for an item related to a certain project.
  • Values of a pick field has been changed (by tailoring for a project   OR   set an entry to inactive)
  • (...)

In case of our company we for eg. use scheduled scripts on daily basis to actualize a state field showing Red/Yellow/Green.

 

Disadvantage of actual behaviour is that script needs to be restarted by hand to get shown the reason why the script stopped.

(Alternatively this can also be taken from server.log, but running script again is quicker).

As next the reason needs to be fixed, run the trigger again,  to get shown may another blocking item and it's reason.

Same procedure:  solving problem, restart script.  Maybe next reason ....     and next reason ....

Especially at the end of a year's quarter when several people leave's company this is a time consuming job to do.

 

BETTER APPROACH  (my idea)

The execution of scripts should work that way, that DB Transaction should cover the change of ONE item only.

If a script should change 200 items, and 3 does contains problematic data, as a result 197 items should be changed,

and a defined administrator should get an email telling him which items hasn't been changed and why.

Benefits:

  • Data quality is better.
  • All reasons (if there are several) will be told within ONE info.
  • Scripts won't get disrupted.
  • No need to check on DAILY basis whether scheduled has run like expected.