Results 1 to 13 of 13
  1. #1
    Join Date
    Mar 2012
    Posts
    1

    Unanswered: Sql server database synch b

    Hi,

    I have created a dotnet windows application (dotnet 3.5, visual studio 2008 editor) and sql server 2008 database as backend.

    Whenever network is available my application connects to server database
    and when network is not available then application connects to local database.


    But next time when application is opened then data and also schema should be synchronized between local database and server database.

    So please tell me how to do this.

    Also primary key columns are set as auto increment in each table.

    Thanks

  2. #2
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    AND the schema?

    Doesn't this just sound like a very bad idea to you?
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  3. #3
    Join Date
    Mar 2012
    Location
    Somewhere In Europe
    Posts
    24
    Hi Pras

    You can use database replication to sync databases, but there can occur data conflicts. I have to agree with Brett, it's not good idea.

    Regards
    Mike

  4. #4
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Specifically you'll want to use Merge Replication.
    I don't know how it will handle the out-of-sync identity key values.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  5. #5
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    Quote Originally Posted by Mikefox1207 View Post
    I have to agree with Brett

    Regards
    Mike

    And as OFTEN as that happens...it never gets old

    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  6. #6
    Join Date
    Nov 2004
    Posts
    1,427
    Provided Answers: 4
    Also primary key columns are set as auto increment in each table.
    You should change the data type of the PK's to GUIDs.
    With kind regards . . . . . SQL Server 2000/2005/2012
    Wim

    Grabel's Law: 2 is not equal to 3 -- not even for very large values of 2.
    Pat Phelan's Law: 2 very definitely CAN equal 3 -- in at least two programming languages

  7. #7
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    Quote Originally Posted by Wim View Post
    You should change the data type of the PK's to GUIDs.
    God Forbid
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  8. #8
    Join Date
    Nov 2004
    Posts
    1,427
    Provided Answers: 4
    God Forbid
    Why? It's the only case I'd ever use GUIDs.
    With kind regards . . . . . SQL Server 2000/2005/2012
    Wim

    Grabel's Law: 2 is not equal to 3 -- not even for very large values of 2.
    Pat Phelan's Law: 2 very definitely CAN equal 3 -- in at least two programming languages

  9. #9
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by Brett Kaiser View Post
    Quote Originally Posted by Wim View Post
    You should change the data type of the PK's to GUIDs.
    God Forbid
    For merging datasets? GUIDs are the best solution.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  10. #10
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    Your better of Architecting a better solution
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  11. #11
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Heavens to murgatroid. I use GUID values and UTC dates/times for any database that requires merge replication. Anything else would beat me bloody!

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  12. #12
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    Any problems with Duplicates?
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  13. #13
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Quote Originally Posted by Brett Kaiser View Post
    Any problems with Duplicates?
    Using carefully contrived lab procedures I can sometimes generate duplicate GUID values. There are a couple of ways that I can do it repeatably, but I can't imagine those happening in the real world.

    Because the GUID is a fixed size, it is guaranteed to have duplicates occur naturally in due time... The most conservative estimate I've seen for an expected collision is over 1800 years, and most estimates are in the tens of millions or more years. Even at 1800 years I don't expect any code I write or even the data associated with that code to be around anymore, and if it is around then I'm pretty comfortable that someone will have a convenient way to deal with the problem by then!

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •