Pro2 and deactivate delete procedure - Forum - OpenEdge Pro2 - Progress Community

Pro2 and deactivate delete procedure

 Forum

Pro2 and deactivate delete procedure

This question is not answered

Hello!

Case is that customer would like to replicate data from OpenEdge to Oracle database. Oracle data is like a master data, where all the data have to remain forever. Using OpenEdge database, customer will remove some old data time to time, but data have to remain in Oracle database always. Can we handle this case with Pro2 so that Pro2 will not delete the data from Oracle database, even it's not exists anymore on OpenEdge database?

Thanks!

Jarmo

All Replies
  • Hi Jarmo

    PRO2 is written in ABL... so everything should be possible.

    So the data created , updated should be propagated to the Oracle Database... but the Delete events should not be applied..

    I guess Terry Mays could give a formal answer...

    Laurent

    Laurent KIEFFER
    Senior Solution Consultant

    PROGRESS SOFTWARE FRANCE

    DIRECT       +33 (0) 4 72 38 52 11 
    MOBILE       +33 (0) 6 15 19 95 95

  • Hi Jarmo,

    Are you talking about auditing maybe?  If that is available in the Oracle database you might consider that.  If you're just talking about marking records as deleted you could definitely customize the Pro2 code to do that.  Like Laurent says, it's ABL.

    You would have to make sure you re-implement your changes in future releases.  In the meantime you could log an Enhancement Request (Idea) for a feature that would allow automatically marking records as deleted in the target.

    Presently there is an auditing feature in Pro2 which avoids deleting the replication queue record in order to post it again to a second target, but this will still apply the deletion to both targets.

    The below article tells you how to log an Idea:

    knowledgebase.progress.com/.../P11255

    Best Regards,

    Ken McIntosh

    Kenneth S. McIntosh

    Principal Technical Support Engineer

     

     

  • Hi Jarmo,

    I think you're talking about Logical Deletes in Pro2.

    From Pro2 User Guide:

    Logical Deletes
    There are times when auditing is not required however it is desired to maintain records in the target database after they are deleted from the source database. In this case, instead of being deleted, rows are designated as “logical” deletes (via PRROWID modification) and the data is kept in the source database.

    Here's an article on how to do it

    https://knowledgebase.progress.com/articles/Article/pro2-how-to-configure-logical-deletes

     

    Best regards,
    Valeriy

  • This can be easily handled in Pro2 by NOT deploying the delete triggers on the OpenEdge database. This means, if you delete any records on the OpenEdge database those records won’t be deleted on the target (ORACLE) database.
     
    Thanks,
    Satya
     
  • Hi Satya,

    Satya Prasad
    This can be easily handled in Pro2 by NOT deploying the delete triggers on the OpenEdge database. This means, if you delete any records on the OpenEdge database those records won’t be deleted on the target (ORACLE) database.

    I don't agree with that. NOT deploying delete triggers will NOT solve this. Also, you can't disable saving a note about deleting a record if you use OE CDC instead of triggers.
    The fact is that if you simply disable delete triggers, you certainly will not delete such records from Oracle through Pro2, but when a record is deleted from OpenEdge, its RECID is released, which can be assigned to another new record in OpenEdge. As a result, when such a record appears, Pro2 will save it in place of the existing "deleted" record in Oracle.
    And this was solved by the Pro2 developers with the Logical Deletes: 

    2) When LOGICAL_DELETE_TABLES is enabled and a record is deleted from the source table, the corresponding record will remain in the foreign database table but is flagged as deleted via its PRROWID. For example,

    Original :
    0x0000000000000356

    PRROWID after record is deleted from the source table:
    D-0x000000000000035620180504-56806

  • I don’t know about the “LOGICAL_DELETE_TABLES” flag. Thanks for the details Valeriy.
     
    Thanks,
    Satya