I have a unique record extraction requirement where I need to pull records that have changed recently but that don't have an explicit timestamp in the table's fields. I've stumbled across a couple of threads on the Internet that say things on the line of
if you use DB2 v9 or later, you can use row change timestamp even if you didn't have the timestamp column
SELECT 1 FROM T1 WHERE ROW CHANGE TIMESTAMP FOR TAB t1 > current timestamp - 1 hours;
Is there anyone in WebFOCUS/Data Migrator land that has coded to this kind of concept that can help me with some of the basics? I'd be much obliged.
J.This message has been edited. Last edited by: <Kathryn Henning>,
April 23, 2013, 05:02 AM
Dear John, The idea seems very appealing to me, so although I have not used it, I tried to work with it and found out in our DB2 V9.5 it is not working as you suggest. According to the IBM DB2 manual you indeed do need a timestamp column on the table defined with CREATE/ALTER table defined as GENERATED FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP. It seems it will become an implicitly hidden column, therefor it seems the table does not have the timestamp, but apparantly it should have been defined in this way to be used in your SELECT statement.
As stated, I did not know about this DB2 feature, and it might be different in other version than our V9.5 (LUW), but this is what I found in the DB2 manual.
WebFocus 8203M, iWay DataMigrator, Windows, DB2 Windows V10.5, MS SQL Server, Azure SQL, Hyperstage, ReportCaster
April 23, 2013, 05:39 AM
It looks like DB2 is an MVCC family database, so it's possible that you could get the information you want from something akin to a transaction id for the records. In general, the higher the transaction id the more recent the row.
Whether that helps depends on what you consider "changed" though. Inserted and updated records will be visible to your current transaction (if committed, of course) and you might be able to obtain the id of the transaction they originated from. Deleted (committed) records however won't be visible to your transaction.
I'm not sure this applies to DB2, but it's worth a shot.
You might want to mention what version and flavour of DB2 we're talking about here