View previous topic :: View next topic
|
Author |
Message |
deybumba_2k
New User
Joined: 09 Jan 2006 Posts: 17
|
|
|
|
Hello,
I am working in a shop where there is DB2 on AS400. The tables in DB2 does not have any"update datetimestamp" column. Now the requirement is to extract rows of few tables which are updated everyday.
For example if today is 06/07, in the nightly batch job, I want to extract the rows of the table which were updated on 06/07.
One option is to insert an additional column for datetimestamp and change all programs to update it going forward whenever an update is made on the table and then extract it based on that column.
Is there any other option (maybe in DB2 Unload utility) where we can achieve the above requirement?
Thanks and appreciate your response.
Subha |
|
Back to top |
|
|
Pandora-Box
Global Moderator
Joined: 07 Sep 2006 Posts: 1592 Location: Andromeda Galaxy
|
|
|
|
Options I see is compare the data which was unloaded yesterday needs to be compared with data extracted today so you could find the delta of changes like records which are inserted , updated and deleted
But a wiser option would be to have a date or timestamp field in the the table
If you dont want to disturb your table structure anticipating any huge impact
why not have a new table created just with keyfields and a timestamp field and populate keydata with current timestamp
So you can process that days's processed records by joining these two tables
Experts would have better word |
|
Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008 Posts: 1020 Location: India
|
|
Back to top |
|
|
deybumba_2k
New User
Joined: 09 Jan 2006 Posts: 17
|
|
|
|
Dear Sushanth,
I got that, but not sure whether that will work with the DB2 on AS400. Saw the feature on DB v29 on Z/OS
Thanks
Subha |
|
Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008 Posts: 1020 Location: India
|
|
|
|
Hi Subha,
Just went to google and typed "DB2 Row change timestamp", the second link i got is this link
I think System i is AS400. So, i think, its there... what version are you using ?
Thanks,
Sushanth |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
If you dont want to disturb your table structure anticipating any huge impact why not have a new table created just with keyfields and a timestamp field and populate keydata with current timestamp. |
Suggest the timestamp be included in the original table.
Other than the table change and including the new column in code that needs it, there should be little/no change to the existing processes. Processes that do not need the new column would need no change. Processes that need the new column have to be changed anyway and i believe it is better to add only some code referring to some column than adding a join of 2 tables.
Some initial value could be placed in the existing rows. Depending on what is done for backup/restore, these might need to be changed. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
you have a potentially huge table that daily has updates to include deletes.
deletes by the way, for which you have no audit......
if you were to create - a new table with columns
- timestamp
- old-table-key
- action - Insert,Update,Delete
- image-type - Before After
- all the columns from old-table
- a trigger on the basic table to populate the new-table
Then:
your unload Program problems would be solved,
(though the analysis pgm would require modifications in order to provide a decent audit trail)
No new code to lay in existing pgrms, just a trigger to INSERT to two (2) rows per modification of base table. |
|
Back to top |
|
|
Pandora-Box
Global Moderator
Joined: 07 Sep 2006 Posts: 1592 Location: Andromeda Galaxy
|
|
|
|
Quote: |
Suggest the timestamp be included in the original table. |
Agreed Dick
Hope he ensures there is no select * anywhere |
|
Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009 Posts: 1281 Location: Belgium
|
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
Does this solution make the problem better or worse? As Mr. Mullins points out, it effectively disables SELECT * even in those cases where it is appropriate. |
|
Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009 Posts: 1281 Location: Belgium
|
|
|
|
I did not see any reference to any application program where SELECT * is appropriate.
But yes, people who need all columns need to be aware of this feature. |
|
Back to top |
|
|
|