locked
Hotfix build 2.00.2501.00 doesn't fix the issue RRS feed

  • Question

  • I'm experiencing the issue identified by http://support.microsoft.com/kb/979735 and applied the hotfix but it didn't fix the issue.  I also tried the recommended workaround in that KB article and that didn't work either. I am running on a 64-bit Win 7 box using the 2.0 collaboration providers (SqlCeSyncProvider/SqlSyncProvider) for a Sql Server 2008 and Sql CE database.  I'm at a loss here, Microsoft? 
    Friday, April 9, 2010 3:42 PM

All replies

  • Could you provide some more information about your schema and constraints?  Are you seeing the repeated traces shown in the hotfix description?

    Thanks-

    Phil

    Friday, April 9, 2010 4:47 PM
    Answerer
  • Phil, sure, the issue seems to be that I have a bigint primary key field, as well as another field which is of type timestamp in the same table.  And yes, I do get the repeated traces.  There is no explicit unique constraint on the table.  I've isolated my issue to be the timestamp field b/c if I remove that field from the server-side db, the problem goes away.  Unfortunately, that is not an option for production. Thanks.
    Friday, April 9, 2010 6:31 PM
  • I'm looking at the specifics of your issue as to why this is happening, but was wondering how the timestamp column is figured into your scenario and how is the client using it?  I ask because synchronizing timestamp columns is difficult since the values can only be assigned by the local database.  Is the client interested in the server's timestamp values?

     

    Thanks-

    Phil

     

    Wednesday, April 14, 2010 5:38 PM
    Answerer
  • The timestamp column serves as the version of the given row.  The client is interested in this value for a number of reasons, one of which is that the version flows from the client to the server upon saves/updates to serve as a concurrency check (we're using EF 4 for persistence).  So it's not an option for us to simply not sync it.  Also, we don't want to change this column's data type to an int/bigint + custom app logic to increment it on saves/udpates just to get around a sync problem.

    Thanks

    Wednesday, April 14, 2010 6:26 PM
  • Phil can I please get an update on this?
    Thursday, April 22, 2010 2:36 PM
  • Sorry I didn't get a notification that there had been an update on this thread.

    I don't think your scenario is possible even outside of this specific sync issue from a database engine perspective.  If I understand your timestamp column usage correctly, you want the server's value to be downloaded and written to the timestamp column by sync, but you also want any client operation to leverage the fact that the timestamp column will automatically update. 

    Timestamp columns cannot be written explicitly and can only be set by the database engine upon a DML operation, so having sync (or any DML) explicitly set the value is not possible.

    Obviously we shouldn't be infinitely looping in this scenario so I will investigate, however I don't think this usage of timestamp columns is feasible.

    Thanks-

    Phil

    Thursday, April 22, 2010 9:05 PM
    Answerer
  • Thanks Phil, let me clarify ... we are not writing to the client database, the sync is a download only scenario so we are not trying to set the timestamp column clientside.  All we need is to just have that value present clientside, no manipulation of it will be done, it just needs to be there.
    Friday, April 23, 2010 12:08 PM
  • In that case it seems like you could map the type to be a bigint on the CE side so that the value can successfully be set.  You can do this by altering the columns type in the DbSyncTableDescription before using SqlCeSyncScopeProvisioning to create the CE client.

    Hope that helps-

    Phil

    • Proposed as answer by Jandeep Thursday, April 29, 2010 11:47 PM
    Tuesday, April 27, 2010 3:51 PM
    Answerer
  • That makes sense, however, upon changing the timestamp column type to bigint on the DbSyncTableDescription and then calling Syncrhonize() on the orchestrator, the sync throws an error stating that the column does not exist.  I looked at the provisioned *_selectChanges sproc and the column is of course not there, even though it is in the DbSyncTableDescription.  Looking into it through Reflector, the problem is in SqlSyncProcedureHelper.BuildSelectIncrementalChangesCommand() ... NonPkMutableColumns does not contain my timestamp field and I see no way of getting it in there as this is private method of an internal class??!!
    Wednesday, April 28, 2010 12:42 PM