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