Synch via DataSet DiffGrams - is there a flaw here?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm looking at how best to synchronize a semi-connected client d/b with a central server d/b and thinking about serialized DataSets over Web Services. All well and good

On the client side I can do something like keeping a DataSet in memory and calling GetChanges() on it to send just a DiffGram of what has changed up to the server when I need to synch. This works fine; you only need to send changed data and a Command object on the server can process the DiffGram pretty much automatically

But. I then need to pick up server-side changes (made by other people, at some point in the past) and send them back down to the client to complete the synch. Obviously I can track what records are new/amended/deleted in my database. But I'd then like to do the same as the client->server leg. ie. get a DiffGram, serialize it back to the Client and use a Command object to update the client d/b. I don't want to send the whole data set back and it's obviously a much sweeter design if the same mechanism for updating is being used client and server side. Yet I can see no way to easily generate a DiffGram of my server changes. The database knows what rows are new/amended/deleted according to an internal scheme I can create, but how to end up with a DataSet whose rows have the relevant RowState? I can get there manually but it is ugly (eg. to make a row "Modified" I can make a non-destructive change to the row to change its RowState). But this surely defeats the object of using the in-built mechanism of ADO.Net. Am I missing something here

Right now the only solution I can see is to ignore DiffGrams as they seem to have this gap in what they do. I guess I can just serialize my own rows with their own flags and handle everything manually ...
 
You probably need to keep track of the server-side state at sync time,
such as by storing a timestamp or a revision counter on the data to
synchronize.

This would allow you to:
o Send diff to client
o Store revision counter for the client
o Receive diff from client
o Apply diff (no hassles here)
o Send diff between current state and client revision state

Keeping track of deleted stuff is always problematic. If your dataset
is not too large it may be easier to simply store the latest version
used in a sync (i.e. an xml snapshot) for every client (rather than
keeping track of revisions).

Yours,
Morten


Simon said:
I'm looking at how best to synchronize a semi-connected client d/b with a central server d/b and thinking about serialized DataSets over Web Services. All well and good.

On the client side I can do something like keeping a DataSet in memory and calling GetChanges() on it to send just a DiffGram of what has changed up to the server when I need to synch. This works fine; you only need to send changed data and a Command object on the server can process the DiffGram pretty much automatically.

But. I then need to pick up server-side changes (made by other people, at some point in the past) and send them back down to the client to complete the synch. Obviously I can track what records are new/amended/deleted in my database. But I'd then like to do the same as the client->server leg. ie. get a DiffGram, serialize it back to the Client and use a Command object to update the client d/b. I don't want to send the whole data set back and it's obviously a much sweeter design if the same mechanism for updating is being used client and server side. Yet I can see no way to easily generate a DiffGram of my server changes. The database knows what rows are new/amended/deleted according to an internal scheme I can create, but how to end up with a DataSet whose rows have the relevant RowState? I can get there manually but it is ugly (eg. to make a row "Modified" I can make a non-destructive change to the row to change its RowState). But this surely defeats the object of using t
Click to expand...
he in-built mechanism of ADO.Net. Am I missing something here?
 
Thanks for replying Morten

In fact I am using the revision counter approach server side - so I know what I'd like to put in my DiffGram. I just can't see a sweet way of doing so! Amends are reasonably easy - if I use ImportRow on rows which I know to be amended into a fresh DataSet, then I get the RowState of Modified. And since I'm doing Deletes as a special sort of Amend thaey work too. It's new rows that is the problem. If my d/b says a row is new I need to get it into a DataSet with a RowState of Added. The only way of found of doing this so far is by calling NewRow and copying the data cross column by column, which is horrible - and not very automatic. So much so that I couldn't help thinking I'd missed an obvious trick ...
 
Update : ImportDataRow() seems to be the key; it allows me to get my data but sets the RowState to Added. OK, so now it's only an ugly hack rather than a flaw in ADO.Net ...
 
Simon said:
Update : ImportDataRow() seems to be the key; it allows me to get my
data but sets the RowState to Added. OK, so now it's only an ugly
hack rather than a flaw in ADO.Net ...
Click to expand...

A hack is better than lots of manual work ;) Glad you made it work!

Yours,
Morten
 
Back
Top