Verify Success/Failure of Batch Schema Change - Forum - OpenEdge General - Progress Community

Verify Success/Failure of Batch Schema Change

 Forum

Verify Success/Failure of Batch Schema Change

This question is not answered

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.

Paul

Paul Koufalis
White Star Software

pk@wss.com
@oeDBA (https://twitter.com/oeDBA)

ProTop: The #1 Free OpenEdge DB Monitoring Tool
http://protop.wss.com
All Replies
  • We create a delta DF between old db and new db after applying DF in batch.

  • > 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).

  • Check version.cfg and use the appropriate method to check?
     
    Scott
     
    ==============================================
    Scott M. Dulecki                   MPUG 16 Aug
    Progress                          WMPUG 17 Aug
    616/481-4313                   SEUG 10-12 Sept
    sdulecki@progress.com            MWUG 8-10 Oct
    ==============================================
     
  • 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.

    Paul Koufalis
    White Star Software

    pk@wss.com
    @oeDBA (https://twitter.com/oeDBA)

    ProTop: The #1 Free OpenEdge DB Monitoring Tool
    http://protop.wss.com