Will DownloadOnly sync delete records? RRS feed

  • Question

  • I have a table whose sync direction is downloadonly. I'm deleting some records in the central database and is there a way to delete those records in the local SDF file too ?
    Thursday, December 15, 2011 4:12 AM

All replies

  • the download operations should apply inserts, updates and deletes from the source to the target.
    Thursday, December 15, 2011 5:35 AM
  • You mean the Incremental Inserts,Updates and Delete command to be set for the DownloadOnly table will delete the records when there is no equivalent record in the SQL server ?
    Thursday, December 15, 2011 12:47 PM
  • it will only delete if the source is deleted. if a row is deleted in the server, a delete is applied to the client. Sync framework applies changes incrementally. its based on recording the inserts, updates and deletes. if the insert, update or delete is not recorded, it has no idea about it.

    its not like its going to compare the two replicas and delete from one side what it cant find on the other.

    Thursday, December 15, 2011 1:05 PM
  • I believe the insert,update,delete record is by the use of ID column and Timestamp columns. If not can you redirect me to a sample on how to record insert, update, delete ?
    Thursday, December 15, 2011 2:00 PM
  • sync framework does that for you already...

    would you mind sharing what is it exactly that you want to achieve?

    your initial question is if rows deleted on the server will be deleted in the client in a downloadonly direction and the answer is yes. there is nothing special to achieve that functionality and sync framework does that out of the box.


    Thursday, December 15, 2011 2:23 PM
  • I have all the things in place for sync. Deleted a record in the server and was expecting the data to be deleted from the client as well which didn't happen. Thought i was missing something. Will check it again.
    Sunday, December 18, 2011 5:35 AM
  • are you using filters? has the row that's been deleted gone out of scope?

    let's say you have a filter State = WA, then you sync a client so that it gets all State=WA rows.

    Now on the server you updated all rows where State=WA to be State=CA. this update will not cascade to your client. likewise if you delete all State=CA, it will not cascade to the client as well. so your client will have records that are out of its scope (theyre no longer WA but CA) and are none existent on the server.

    Monday, December 19, 2011 3:28 AM
  • Couple of scenarios'..

    1. I have filtered records based on a filter. I use a filter(dynamic) "Where UserCode = 'INS'. Now all the records would get downloaded matching this condition. After sometime, the user is mapped to some other code and now the filter reads "Where UserCode ='UPD'. My question is will the sync delete the older records corresponding to UserCode = 'INS' in the local store? I want to reduce the size of data in the local store.

    2. Sync downloads a particular table (download only) data to 2 users. There happens to be a delete action by one user in the central data store and will that data be deleted from the local store of another user ?

    Tuesday, December 20, 2011 5:23 AM
  • 1. No, it will not be deleted - this is what i referred to as rows going out of scope (also referred to as partition realignment). When Sync Framework enumerates changes, it looks at the changes that happened at the row, not the filter. and even if those rows has changed, the new filter condition would effectively filter them out as well. If you're doing Download only sync, you can simply delete them from the client. Be careful deleting the rows from the client in a Bidirectional sync as the deletes will be applied on the server as well. you dont want to delete the server rows, you just want to clean up the rows irrelevant to the client.

    2. yes, if you dont have a filter based on user or if the filter condition for a client is satisfied,  the delete that has happened in the server, that would be applied to whichever client syncs and gets that change.

    Tuesday, December 20, 2011 5:57 AM