Duplicate row errors in DMS Scripts

IGNORE_DUPS Vs UPDATE_DUPS
Often we get the Duplicate row errors in the DMS Scripts based on the target environment in which import script is executed. Since DMS scripts can run in any target environment we need to handle this error in the DMS Script.

The best know method is IGNORE_DUPS statement in the DMS script
SET IGNORE_DUPS ;
IMPORT {record * } ;

The biggest disadvantage of this statement is it can only be run 'Bootstrap mode' which all the developers may not have access.

Is there way to avoid handle this error wihout running the DMS in the bootstrap mode ?

SET UPDATE_DUPS;
IMPORT { Record * };

Above statment can be used, it is not an exact replacement for the IGNORE_DUPS but it helps to slove problems in most of the cases.
UPDATE_DUPS - If the key values of the table exists in the target environment then it updates it with new values and insert the new rows in the .dat file.

1 comments  

Invoking the Remote call from AE/CI Process

In PT 8.4x you need to follow a certain sequence prior to invoking the PushButton field. The basics on calling COBOL from AE/CI PeopleCode is as follows. Note that "tweaking" may be necessary to get it to work.

1. AE (Application Engine) needs to have restart disabled in order to use CommitWork() to force a commit to the DB of the CI data.
2. Set the CI's properties, except for the "Pushbutton" field (usually Y/N) used to kick off COBOL.
3. Save the CI (call Save()).
4. If Save is successful, call CommitWork().
5. Set the CI pushbutton property (toggle it) to trigger the COBOL process.
6. COBOL will run asynchronously. So you usually need to put a dummy loop to wait until it's done processing to avoid having the next CI record "bump" into COBOL or in case you need to perform some post COBOL processing of the record.

3 comments