Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
MSF 2.0 - Stored Procedure SelectChanges return 0 results ! RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I've provisioned a table on SQL 2005

    • create tables = true
    • create metadata = true
    there are 15.000 rows of data in the table, and after the provisioning is done, there are 15.000 rows in the _TrackingTable

    When i now call SelectChanges using the values that .Sync() uses, i get 0 results !!!!

    1.500.000 other rows from other tables were synced just fine !!!!


    WTF !?

    Thursday, November 11, 2010 3:02 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    the local_create_peer_timestamp in the tackingtable is : 33.548.508

    and the timestamp for the sync call is : 37.847.375

    so in essence... the Synchronizer is using a value too high ?

    in one of the tables that WERE synced... the local_create_peer_timestamp is 156.627.054 (4.7 TIMES HIGHER NUMBER !!!! WTF !!)

     

    is it possible that some tables are using another time-zone ?... or leap Millennium ?

     

    i'm going Gazaaa !!

    Thursday, November 11, 2010 3:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    actually, the SQL data type timestamp has nothing to do with date and time. they're a sequence of binary number that get's assigned (autoincremented) everytime you create/update the row.

     

    Thursday, November 11, 2010 4:16 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    1. its called "timestamp"
    2. why is the storedprocedure doing a "larger then" comparison if the value is an arbitrary binary ?
    Thursday, November 11, 2010 6:08 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    it's misleading...the more appropriate nameiis rowversion: http://msdn.microsoft.com/en-us/library/ms182776.aspx

    it's not an arbitrary number, its an auto-incrementing number

    Thursday, November 11, 2010 11:43 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    so you don't see a problem that the "number" is used for comparison of versions - and that one number is 4.7 times higher then another ?

    it might be the reason why some tables doesn't sync in my case :-/

     

    edit:

    i might have found another problem... 

    one server is using Danish date formatting: dd-mm-yyyy

    while the other is English: mm/dd/yyyy

    could this be causing the problems ?

    Friday, November 12, 2010 12:30 PM