Are you sure you need to have 2 separate databases, on different servers, rather than just one database and the two separate clients accessing the database? That would make things much easier :).

If you do need two separate databases, you will need a ROWGUIDCOL to serves as your primary keys ROWGUIDs are unique across time and space (and therefore, your two separate databases). When one is replicated to the other, you do not need to worry about duplicate primary keys.

>We're not talking about a deployed system so I haven't set it up to do anything yet. What I have now is 2 completely separate client (one VB other ASP) applications sharing "one" MSSQL DB that'll need to be separated at deployment.
>
>If you're asking if the updates on both DB needs to merge, of course (at least once a day if not more frequently). That's the architectural question I want some suggestions to. How can I set this up so that the replication between the two DB is as seamless as possible? Thanks.
>
>>Is there any replication between the two databases? In other words, if records are updated on the subset database, do they at some point get merged to the main database?