Urgent Help: Unable to set session parameters in DbServerSyncProvider. Cannot obtain the value for command parameter '@sync_client_id_binary'. RRS feed

  • Question

  • We have a VS2008 project wich works perfectly on develpment enviroment (Windows 7, VS2008). The project consist on a Win CE smart device project and a Sync Framework WCF webservice.

    When we deploy it  on a stagging enviroment every time we try to sync it throws the following error: "Urgent Help: Unable to set session parameters in DbServerSyncProvider. Cannot obtain the value for command parameter '@sync_client_id_binary'."

    There is not enough information on the web to help solve this issue and after trying many things I don't really have a clue yet.

    I Appreciate any help about it tnx!

    Wednesday, May 9, 2012 12:58 PM

All replies

  • Stagging enviroment is Windows Server 2008 with IIS 7 and Sql 2008
    Wednesday, May 9, 2012 1:07 PM
  • try setting the ClientId  property of the SqlCeClientSyncProvider
    Wednesday, May 9, 2012 1:26 PM
  • I used VS2008 SyncFramework wizzad to generate the WS and client code. Where can I find this ClientId property?, I mean how should i set this property, and i dont why works on a dev enviroment and not in the other.

    And where should I do that on the service or on the client

    • Edited by MaxGuillen Wednesday, May 9, 2012 2:04 PM
    Wednesday, May 9, 2012 2:02 PM
  • I fixed it! this post helped me a bit: 

    The problem was, the generated Sync framework code for the WS that was created using the sync framework wizard was, used version of the following, dlls referenced from the GAC:

    Even when I installed on the server SSCERuntime-ENU.msi the version of the dlls were´t the same.So I added local references of this dlls in the WS project.


    I took this dlls from the following paths:
    C:\Program Files (x86)\Microsoft SDKs\Microsoft Sync Framework\v1.0\Runtime\x86\
    C:\Program Files (x86)\Microsoft Synchronization Services\ADO.NET\v1.0\

    I redeployed the WS and now It works fine!

    So I think the problem was that a diferent version of the dll was looking for ClientId on a diferent place. Like Bryan Dougherty said in that post:
    "...That seems to set it up properly for change tracking using the __sysSyncArticles and __sysSyncSubscriptions tables instead of the __SyncArticles and __SyncSubscriptions..."
    • Edited by MaxGuillen Wednesday, May 9, 2012 9:03 PM
    • Proposed as answer by JuneT Thursday, May 10, 2012 1:11 AM
    Wednesday, May 9, 2012 9:02 PM