Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
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-CacheStamp3. _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.
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).
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.