locked
Question to Demo I, Deletes twice RRS feed

  • Question

  • As an introduction to SyncServices I installed and executed Demo I from Rafik Robeal. Everything works fine, but I have a question. When I delete a row on the client it seems that the row is deleted twice. First I have the 6 enumeration sentences for insert, updates and deletes of order and order_details. Delete for orders shows (0|0|1) so everything is fine. Afterwards "Applying delete" really deletes the entry in the database. I checked this. Now 6 lines for the client follow, again with insert, update and deletes. Deletes also shows (0|0|1) (why?). And again the deletion is applied, I think in this case to the client. Should it be that way?

    I also tried the same the other way round. I deleted a row on the server. In this case, the deletion is applied only once. Does someone know the reason?

    • Moved by Max Wang_1983 Friday, April 22, 2011 9:57 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Thursday, October 25, 2007 1:40 PM

Answers

  • Hi Christine

     

    The select deletes command that is generated by the builder on the server side does not filter out deletes by originator. Thus the deletes that were uploaded from the client were downloaded back again since their timestamp is higher than what the client have seen already. You can observe this by using the SQL profiler. You will notice that the select deletes statement does not have the <update_originator_id <> @sync_originator_id> filter as other select statements. In your code, you can fix the statements to the behavior you desire, the adapter builder is just a starting point. I took a note of this and will look into adding this filter in future release.

     

    Thanks,

    Rafik

     

    Thursday, October 25, 2007 6:38 PM

All replies

  • Hi Christine

     

    The select deletes command that is generated by the builder on the server side does not filter out deletes by originator. Thus the deletes that were uploaded from the client were downloaded back again since their timestamp is higher than what the client have seen already. You can observe this by using the SQL profiler. You will notice that the select deletes statement does not have the <update_originator_id <> @sync_originator_id> filter as other select statements. In your code, you can fix the statements to the behavior you desire, the adapter builder is just a starting point. I took a note of this and will look into adding this filter in future release.

     

    Thanks,

    Rafik

     

    Thursday, October 25, 2007 6:38 PM
  • Thanks!
    Monday, October 29, 2007 6:48 AM