Urgent Help: Unable to set session parameters in DbServerSyncProvider. Cannot obtain the value for command parameter '@sync_client_id_binary'.
Wednesday, May 09, 2012 12:58 PM
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 09, 2012 1:07 PMStagging enviroment is Windows Server 2008 with IIS 7 and Sql 2008
Wednesday, May 09, 2012 1:26 PMModeratortry setting the ClientId property of the SqlCeClientSyncProvider
Wednesday, May 09, 2012 2:02 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 09, 2012 2:04 PM
Wednesday, May 09, 2012 9:02 PMI 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 184.108.40.206 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..."