ChangeTracking columns not included in schema when using CoupledChangeTracking RRS feed

  • Question

  • We're using SQL 2008 on the server end and SQL CE on the client end for a .NET windows application (occasionally connected)

    I am refactoring our solution to eliminate the use of the integrated SQL server change tracking feature for several reasons that are not relevant.

    I want to use the basic CoupledChangeTracking approach.  For the most part it is all working fine, but I do have one problem.

    It seems that the columns that I specify as my insert/update change tracking columns are NOT included in the table schema that is brought down to the local SQLCE clients.

    For my implementation this is a problem, and I want my tracking columns included in the local storage.  Is this behavior normal and is there a way I can work around it?

    Please let me know if there are any other relevant details I need to include for this question.




    Friday, June 18, 2010 9:58 PM

All replies

  • 1. In general, the tracking columns are not recommended to downloading to the (SQL CE) client side.

    2. Since you have a special requirement, then you could try to include those columns during download phase.  But please do not include them for upload.  You could try to modify the SelectIncrementalInsertCommand and SelectIncrementalUpdateCommand to include the tracking column.

    By the way what business requirement do you have so that you need to include these 2 columns?


    Leo Zhou ------ This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, June 19, 2010 3:33 AM
  • Leo,

    My implementation is unidirectional, I only pull data down to the clients.  So including these columns in the upload would not be an issue.

    Is there a standardized approach to modifying the select commands?  I am using a FilterClause on my adapter builder but I believe that is only for "WHERE" clause type modifications.  Not sure exactly how to go about including other columns.

    I will try to explain the business requirement.  Before we started using sync fw, we already had date and time stamp columns set up with triggers (createdDate and LastUpdatedDate).  My business objects expose these values as properties and there are several places throughout the app where they are referenced for various purposes.  Rather than create two new (redundant) columns, we want to use these two that already existed.

    Our goal is to make the offline experience as transparent as possible and not have to make changes throughout the app.  Basically, the data "fetches" that occur against the SQL CE client database are not even including these columns in the result set and causing problems. 

    I can think of some other ways around it but it would sure be nice if the columns were just included.  Having a different schema at client and server, at least in my case, is disadvantageous.



    Monday, June 21, 2010 3:05 PM
  • did you use the Local Database Cache item in VS or did you code the SQL commands  yourself?
    Tuesday, June 22, 2010 10:46 AM
  • I did not use any of the tooling in VS.  The implementation is coded myself - however - it was not necessary for me to manually code any SQL commands for the synchronization.  So I'm not sure if I understand your question properly.





    Tuesday, June 22, 2010 7:46 PM