locked
UploadOnly erases all data on client after sync RRS feed

  • Question

  • UploadOnly erases all data on device client after sync (in all tables with UploadOnly participating in sync). Is this intended behavior? Did I misconfigured something? Or is there more to it? Haven't found any mention of what UploadOnly actually does in the docs.

    All other direction seem to be working fine.

    • Moved by Max Wang_1983 Friday, April 22, 2011 6:30 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Thursday, August 7, 2008 1:36 PM

Answers

  • Hello,

     

    Let me clarify a few things before we continue the issue debugging.

    1. You have existing tables on the device before doing any synchronization, right?

    2. You see tables on the device are all empty right after the first sync, right?

     

    If both 1 and 2 are true, then I think this is an expected behavior, due to TableCreationOption is DropExistingOrCreateNew.  Because exiting table on the client is removed and recreated before uploading changes during first sync.  Since you are doing UploadOnly sync, there is no data coming down from the server.  So you see the empty table.

     

    After each incremental sync, (of course user input has been uploaded to the server), if you still see the empty table, then this is something special we need to investigate.

     

    As to the user's runtime exception, this could be very likely due to the newly re-created table on device.

     

    Thanks.

    Wednesday, August 13, 2008 9:18 PM
    Answerer

All replies

  •  

    this is not the expected behavior. syncdireciton.UploadOnly simply means it willy send the changes from the client to the server, while not changes from server to clients.

     

    could you describe your case in details and provide some code you have for the sync ?

     

    thanks

    Yunwen

    Thursday, August 7, 2008 11:05 PM
    Moderator
  • Hello,

     

    Do you mind showing the TableCreationOption for each SyncTable object?

     

    Thanks,

    Friday, August 8, 2008 4:33 AM
    Answerer
  • Looks like this issue is not UploadOnly related. It happens while I try to access any data while sync is going in the background. If I stop debug while in sync and look at tables with Query Analyzer all tables are somehow empty. After sync everything works as it should. So no point running asynchronuously.

    This could be related to DropExistingOrCreateNewTable option that I use. But then again why would it recreate a table that is already there? Or should different options be used each time? Like see if table exists, recreate if needed and then UseExistingTableOrFail.

    The code is mostly taken from device sample (different tables and queries of course).

    Monday, August 11, 2008 6:33 AM
  • UploadOnly has issues after all. Tables are always empty after it.

    Monday, August 11, 2008 7:18 AM
  • I get SqlCeException with:

    The table schema has changed since the query was last compiled. Recompile the query.

    So why is it being changed? Not like there where any changes. This usually happens when first syncing data back (bidirectional, since UploadOnly kill all data) in the background after initial synchronuous sync.

     

    Monday, August 11, 2008 7:41 AM
  • So looks like this issue can be reproduced.  Do you mind provide more details so that I could do a debug?  Thanks

     

    1. How does the server table look like and how does the client tables look like?

    2. How many processes touches these tables on the client?

    3. The sync direction is UploadOnly right?

    4. The table creation option is DropExistingOrCreateNew, right?

    5. Does any process change table schema, except the sync process?

     

    Did you try other table creation option?

    Can you tell more about your besiness scenario?

     

    Thanks

    Monday, August 11, 2008 7:48 AM
    Answerer
  • 1. Table look like:

    Key, Field1, Field2, ..., SystemField1, SystemField2, ...

    Only non-system or fields that are required on the client are synced. So clients have only a subset of server fields.

    2. 1 process, 2 threads: 1 sync thread (I can only guess), 1 interface/logic thread

    3. Yes

    4. Yes

    5. No

     

    Haven't tried other options, since they are not appropriate.

     

    Scenario (with Bidirectional, since UploadOnly just kills data):

    - cache tables are updated synchronuously (that are not user-dependant)

    - user signs in

    - user-specific tables are updated synchronuously

    - user selects task to activate

    - first asynchronuous sync is initiated to sync that change (activated task) back

    - if some data is accessed while sync is active and that table is currenly synced (that is either empty or being recreated) I get the error above

    - if UploadOnly was used all tables are empty after this sync, if Bidirectional - data can be accessed normally

    - subsequent bidirectional syncs don't produce same error even if data is accessed while sync is running

    Monday, August 11, 2008 8:21 AM
  • One more thing I forget to ask - do user DMLthread share the same SqlCE transaction as the Sync thread?  Thanks.

    Wednesday, August 13, 2008 6:54 PM
    Answerer
  • Hello,

     

    Let me clarify a few things before we continue the issue debugging.

    1. You have existing tables on the device before doing any synchronization, right?

    2. You see tables on the device are all empty right after the first sync, right?

     

    If both 1 and 2 are true, then I think this is an expected behavior, due to TableCreationOption is DropExistingOrCreateNew.  Because exiting table on the client is removed and recreated before uploading changes during first sync.  Since you are doing UploadOnly sync, there is no data coming down from the server.  So you see the empty table.

     

    After each incremental sync, (of course user input has been uploaded to the server), if you still see the empty table, then this is something special we need to investigate.

     

    As to the user's runtime exception, this could be very likely due to the newly re-created table on device.

     

    Thanks.

    Wednesday, August 13, 2008 9:18 PM
    Answerer