July 21, 2009 at 5:57 am
Hello everyone.
The @@DBTS value of my db before back-up is not equal after restore. Does any one knows how this value changes and how can I prevent this change?
July 21, 2009 at 8:32 am
I would highly doubt that there is a way to change this. Can you explain what you are using this for? My guess is that you are going to have to seek an alternative solution.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
July 21, 2009 at 9:04 am
This behavior is documented by MS titled "Backing Up and Restoring a Database (Sync Services)" at http://msdn.microsoft.com/en-us/library/bb726016.aspx
SQL = Scarcely Qualifies as a Language
July 21, 2009 at 9:22 am
Following comment give your answer:
@@DBTS returns the last-used timestamp value of the current database. A new timestamp value is generated when a row with a timestamp column is inserted or updated.
July 22, 2009 at 12:14 am
Carl Federl (7/21/2009)
This behavior is not same as explained. In my case @@DBTS increased but not decreased. I implemented the sync. scenario like msdn says. I found a solution without keeping @@DBTS unchanged, but I am realy curious about how last timestamp changes after restore happens. I assume @@DBTS value should be same before backup and after restore, but it was not. I realized that after restore, @@DBTS increased about data count in the database.
February 2, 2010 at 12:22 pm
I'm continuing this post cause it seems to be regarding the same "issue" i'm having.
Scenario:
We are developing a syncronization utility between a central DB and some occasionally cnnected clients using Ms Sync Framework v2 RTM.
Both client and server are using SQL Server 2008 (Express edition on clients machines) and we are using tracking tables (instead of the sql server 2008 change tracking feature) to keep track of changes; those tables are updated by some triggers, each tracking table has a timestamp (rowversion) column used to know which records are modifies/added/deleted from the lasy synchronization with a client.
We are facing some weird behaviour of newly created clients (we just restore a copy of server dbs on the client machine and do some stuff with timestamps). We are still investigating on that weird behaviour and we think it might be related to "something" done by sqlkl server right before a backup.
EXAMPLE:
I have a database with some tables (with timestamp column), lets call it myDB.
After working on data (so the timestamp value grows) i check the last value with SELECT @@DBTS
The value, for this example, is 10000.
If i backup the db and then restore it as myRestoredDB, after doing a SELECT @@DBTS i will get something like 11235 and not 10000, that means that something has been done before backing up myDB. (NOTE: no pending transactions before backing up the db )
So i tried the following thing:
I changed some data on myDB, verified the timestamp value with SELECT @@DBTS (this time was 12000), then i set myDB OFFLINE and then back ONLINE, did my SELECT @@DBTS once again and the returned value was 13426.
I did my backup and then restored the db as myDBRestored2, now executed SELECT @@DBTS and last timestamp was, as expected, 13426.
What is Sql server doing to the database when i set it OFFLINE (or before doing a backup)?
I need to do the same things before doing the backup, of course OFFLINE mode is not an option, any suggestion is really helpful.
Tried already to google about that, but i havent found anything useful.
Tried also to shrink the log file and force a checkpoint, obviously with no results.
Thanks
Damiano
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply