I have to work with a database which keeps a track of instances of certain events on a network. I want to be able to keep my own copy of those on another database elsewhere.
The issue I have is keeping in sync with updates. If a record changes on database A I want to then update database B with the changes. Simple enough but database A doesn’t have any form of modified timestamp field, and I cannot change the database at all (not even to add triggers). I am writing a C# application which will be doing the syncronisation on an hourly basis. (This is acceptable to my requirements, data doesn’t have to be fresh all of the time).
My question is this:
If I use BINARY_CHECKSUM, I can presumably keep a list elsewhere (memory/XML/whatever) of the expected value, then periodically check to see if it is different. If it is different I can then sync the row manually in code.
Is this a good idea? Is there a large overhead associated with BINARY_CHECKSUM? Is there a better way to detect changes to a row that I cannot change?
EDIT: I am fully aware of SQL replication, however I should have mentioned that the two databases are not on the same network, and interfacing between them is done via web services accessed by C#.
Cheers,
Posted this in a comment to Jobo’s answer:
Result:
So no, I wouldn’t recommend
BINARY_CHECKSUMas a means to keep databases in sync.Remember that any form of hashing is a good means to determine that two inputs are definitely different (if the result of the hash is different), but if the results are the same, you usually have to check all of the specific values to determine if the inputs are really the same or just have the same hash value.
The exception is if you’re using a balanced hash function of sufficient length that collisions are so unlikely that you won’t see one in your lifetime.
int, at 32 bits, is not long enough.