Hi,
I am trying to do incremental loads. I need to select the max timestamp from the target table, compare it with a timestamp value in the Source table and select all rows which are greater than the max timestamp.
I am trying to use the lookup stage in parallel to do this but need some suggestions on how to go about the same.
Thanks in advance,
Hema
Comparing with max timestamp
Moderators: chulett, rschirm, roy
If both the tables are in the same schema then you can do it in one database stage itself.
Something like
Something like
Code: Select all
select * from TABLE1
where timestampColumn > (select Max(Timestamp) from TABLE2)
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
Thanks for the response. Actually, I am trying to do incremental loads from an audit table which has thousands of rows added to it everyday. So if I run the job today it should only pick up those rows which were added after yesterday's load. So the logic is timestampcol > max(yesterday's timestamps). I can't figure out how to incorporate this into Datastage. Any ideas?DSguru2B wrote:If both the tables are in the same schema then you can do it in one database stage itself.
Something likeCode: Select all
select * from TABLE1 where timestampColumn > (select Max(Timestamp) from TABLE2)
One more thing, I want to run this query from a user defined sql file. But that option doesnt seem to work in datastage. Is this a bug ?
Cheers
Hema
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Which database and which database stage are you using?
You could certainly use an SQL file from a shell script executed from an Execute Command activity in a job sequence.
You could certainly use an SQL file from a shell script executed from an Execute Command activity in a job sequence.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.