10.2B08: How to check the last change timestamp of a table? - Forum - OpenEdge RDBMS - Progress Community

10.2B08: How to check the last change timestamp of a table?

 Forum

10.2B08: How to check the last change timestamp of a table?

This question is answered

Is there a technical option to request the last change of a table?
(to avoid adding a manual timestamp field to each record with index or a trigger for every table)

Verified Answer
  • There is no such secret field.

    --
    Tom Bascom
    603 396 4886
    tom@greenfieldtech.com

    --
    Tom Bascom
    tom@wss.com

All Replies
  • It depends what you mean be last change? Do you mean the last time a record on that table was updated?

    There is a last changed field on the system table that contains table information but I believe that is the last time the schema of that table changed so is not of much use to you if you want CRUD info.

    OE Auditing might be able to do what you want. Not sure which Progress version that came in though, and requires some careful thought in terms of implementation.

  • Any modification: add, update or delete. Schema change is no problem, it's in _crc

    Auditing is too much overhead, i think it's already available in 10.2B

  • The advantage of Auditing is that you don't need a code change to implement it. I've only dabbled in it a little myself, so I don't know if you could configure it to just report what you want.

    Other than that you'll need trigger code and a schema change as you suggest.

  • I have to read about it in the past.

    But i think i read that i need an audit database with monitoring and so on.

    If there is a secrect field in the system tables which reflects the last data change in the table, this would be perfect.

    Then there is no need for code change too.

    But it looks like it isn't :-(

  • There is no such secret field.

    --
    Tom Bascom
    603 396 4886
    tom@greenfieldtech.com

    --
    Tom Bascom
    tom@wss.com

  • OE Auditing was added in 10.1A.  While it doesn't require application changes per se, making code changes can enable richer audit data like application context, if that's interesting to you.  If you use auditing I recommend you add an audit archive database and regularly transfer your production audit data to it (via auditarchive/audit load) for querying and reporting.  There are other best practices I haven't mentioned that you should research before implementing auditing.

    What is the use case for adding the update time stamp?  Do you need it on all tables or just a subset?

  • To speed up our selfmade replication, currently we have triggers but i like to remove them to increase performance.

  • Is OE Replication Plus an option for you, instead of rolling your own?

  • Oh, misleading answer. It's for updating a MS SQL report database, sync only one time in the night and on request.

  • And if you can't use OE Replication Plus can you roll something using After Imaging?

  • Ah ok - that's different.