Verify Success/Failure of Batch Schema Change

Posted by Paul Koufalis on 25-Jul-2017 07:50

Recent versions (10 and 11), all platforms.

I am applying DF files in batch. How do I know that they were applied successfully?

There are three schema fields that are good candidates:

1. _file._last-change (Ken McIntosh @ PTS pointed me to a Dimitri Levin post on Progresstalk)
2. _dbStatus._dbstatus-CacheStamp
3. _mstrblk._mstrBlk-TimeStamp

Ken @ PTS said that option 2 does not provide this information.

Options 1 and 3 are promising but do not take into account changes to sequences.

Looking at the load_df.p source code, in version 10 the program relied on _msg, while in version 11 it relies on a try-catch. Since I need to support 10 and 11, I cannot use try-catch. My original solution relied on _msg, but it missed a couple of situations so was not 100% reliable.

According to PTS, there is no solution to my question and I need to log an enhancement request. i would like to know what other people are doing.


All Replies

Posted by e.schutten on 25-Jul-2017 08:05

We create a delta DF between old db and new db after applying DF in batch.

Posted by George Potemkin on 25-Jul-2017 08:33

> 3. _mstrblk._mstrBlk-TimeStamp

Mainly it equates to the maximum of _file._last-change but it will be also updated if you will edit the list of security administrators (_User._Can-Create and _User._Can-Delete).

Posted by Scott Dulecki on 25-Jul-2017 08:54

Check version.cfg and use the appropriate method to check?
Scott M. Dulecki                   MPUG 16 Aug
Progress                          WMPUG 17 Aug
616/481-4313                   SEUG 10-12 Sept            MWUG 8-10 Oct

Posted by Paul Koufalis on 25-Jul-2017 09:09

Thanks Scott, but the _msg solution doesn't actually work in all cases. When you try and load a DF on a DB with connected users, the load_df hits a lock wait timeout and exits. it's likely related to a STOP condition being raised and I'm not handling it properly in my code.

As for try-catch, that code is already in the V11 load_df.p code. The error gets caught there and presumably written to a dot-e file. Colour me skeptical, but I didn't want to rely solely on the existence or not of a dot-e, though I do check that among other things like _file._last-change.

This thread is closed