locked
How is this possible? Sync Framework v.1.0 delete client records??? RRS feed

  • Question

  • In my case, I basically say that if there is a sync conflict on the client, for the server to win on the client side.  However, in some rare instances that I cannot recreate, the clients data is deleted.  What's odd is that I do not delete any of my data, I just mark it with a deleted flag in my apps.  Is there some scenario where the server wins that it would delete the client data?  For now I am just having them sync a fresh database, but as you can imagine, it's torqued off a few people to have to fill out all of that information again. 

    In the instances I'm talking about, I don't believe the client data actually even made it to the server.  If it didn't make it to the server, how could the server see this as data that needs to be deleted and if it does see it as data to be deleted -- how can I prevent it from getting deleted in the future.  Is there some way to tell that changes that are coming are commands to delete a record?

    Any help would be greatly appreciated.


    Travich
    Monday, April 19, 2010 7:31 PM

Answers

  • that means the server has detected deletes on its side and sent it to the client.

    if you're not making physical deletes, how are you flagging the rows as deleted? a straight update to the rows setting a particular flag? or are you doing instead of triggers? have you checked the delete trigger on your table?

    you may want to inspect the dataset on the ApplyingChanges event on the client side, each DataRow in the DataTable inside the Dataset would have a RowState property. The rows marked for deletion will have RowState=Deleted.

    • Marked as answer by travich Tuesday, April 20, 2010 1:44 PM
    Tuesday, April 20, 2010 4:54 AM

All replies

  • you mean the server row overwrites the client row or the client row is deleted from the table?

     

    Monday, April 19, 2010 10:53 PM
  • The client row is deleted from the table. 
    Travich
    Tuesday, April 20, 2010 4:06 AM
  • that means the server has detected deletes on its side and sent it to the client.

    if you're not making physical deletes, how are you flagging the rows as deleted? a straight update to the rows setting a particular flag? or are you doing instead of triggers? have you checked the delete trigger on your table?

    you may want to inspect the dataset on the ApplyingChanges event on the client side, each DataRow in the DataTable inside the Dataset would have a RowState property. The rows marked for deletion will have RowState=Deleted.

    • Marked as answer by travich Tuesday, April 20, 2010 1:44 PM
    Tuesday, April 20, 2010 4:54 AM
  • The marked as deleted, as in, I set a bit field in the DB for each row in the main table, which is just a way to keep a history on deleted field tickets in case someone does not really mean to delete them.  I move them into a nightly archive DB in order to keep the client database small.  If someone needs to access those tickets, I have a layer to communicate to the DB generated through SQL Metal so I can quickly quarry the database in that way.  I query for tickets against this bit flag if the ticket was deleted (or for tickets that are not deleted)

    With that said, NOTHING is truly deleted.  That is, I never truly delete any row from the database.  I keep everything, yet the server has sent the rowstate == deleted to the client for some reason for all of his rows in this table.  The client rows HAD NOT yet made it to the production server.

    If I test for RowState deleted -- do I just cancel the changes to prevent them from occurring via the:

    row.RejectChanges();

    ????

    Thanks for your help on this.  I will mark your top answer as correct for sure, but let me know about my last question if you would.  :)


    Travich
    Tuesday, April 20, 2010 1:44 PM
  • I did realize I contradicted myself -- I DO delete when I move to the archive database.  So I cannot rule that out, but it does not appear that his tickets are in there.  Job for that database is straightforward and look for tickets 90 days or older or that have been deleted...
    Travich
    Tuesday, April 20, 2010 2:35 PM
  • can you verify that the ticket primary key is unique to all clients? that is no two clients generates the same ticket number? e.g. Client A and B both has ticket XYZ, Client A's XYZ row was archived and deleted. When Client A synchs, it get's the delete operation for its ticket. However, when Client B synchs, it also receives a delete for row XYZ and also does a delete even though the deleted row was for Client A's XYZ.

    Wednesday, April 21, 2010 4:00 AM
  • Well, tickets are using Guids generated on the clients machine, so I don't think that would be the case. I do appreciate the thought.
    Travich
    Wednesday, April 21, 2010 4:56 AM