views:

36

answers:

2

I am BI Manager on top of a SAP installation. I have a SAP DB which the SAP application writes data to. In order to get an environment to query without loading on the sap, I have mirrored the SAP DB on a server, and it works fine.

Each night I do a full load of data, and it works fine for now. I know that somewhere down the line, I will have to start doing incremental updates.

This will be a lot easier if I know which rows in the tables have been modified or added, and when. Is it possible to make a trigger on the target server that writes into the table when it was updated or created? A lot of the time, there is no indication of the date the row was created in the source tables. I am not well acquainted with the rules of mirroring and replication

+2  A: 

The easiest way to fix this is probably to update your table to add a timestamp column, and have it default to the current versioing item. You can look here for more information, but the format is basically the following...

ALTER TABLE <tablename> ADD timestamp

As noted in that link, you do not need to specify a column name, as it will automatically start tracking the timestamp during inserts/updates.

Note that this solution does not give you a human readable time - the item given is unique to the (just something that is easy for versioning). If you want a time, you can make a DATETIME column that defaults to GETDATE() (see here for more info). When you insert/update a row, you would just ignore inserting/updating anything in that particular column, and the current DATETIME would be added for you.

allie
Okay, I was thinking in those lines, just was'nt sure that it would work on the target server in a replication chain?
David
I've not done it in a set-up like that, however, if you're adding everything to the target server, the timestamps should all be consistent. Replication should strictly copy the table (see here [http://msdn.microsoft.com/en-us/library/ms151198.aspx]), not reinsert the rows into a new table on the replication chain. Thus, the timestamps shouldn't be changed.
allie
+1 but it doesn't make sense to say "add a timestamp column, and have it default to the current time." It has no time element to it.
Martin Smith
Edited - alas, `timestamp` was a poor choice of syntax naming regarding this, as it is misleading. Hopefully my clarification helps, but I suspect the `timestamp` bit will continue to throw people off.
allie
That's why we're supposed to use the ROWVERSION synonym now.http://msdn.microsoft.com/en-us/library/ms182776.aspx
etliens
A: 

Hello Everybody. Many thanks for the answers. I will have to do my homework and look into the timestamp per row issue.

Just to make sure. Will I be able to query the timestamp in an sql query, so that I can get the rows that has been edited/Inserted within my last update?

Furthermore, I do not have access to the source server due to hosting issues. I have a replication set up, and can only manipulate the target server.

By doing this I will be able to see per row, when it was last updated?

many many thx

David

David