Question

I’m fishing for knowledge on this one as I know a way I could get what I’m after but I’m wondering if it’s the best approach. Due to project creep the database of what was once a very simple application became an overcomplicated monster, and while it worked administration wasn’t exactly easy.

I’ve got the opportunity now to essentially start again, however only piece by piece, gradually migrating functions from the old application to the new one. This requires that I keep the new database synchronised with the old one, which thankfully only needs to be one way as no data will be getting created on the new database that needs to be migrated back.

The options considered so far are SSIS and a Quartz triggered windows service using plain old C# ADO.Net. SSIS I’ve decided is probably a bad idea as it can be a nightmare with upserts, requiring temporary tables to be created followed by a merge and the schema differences are pretty extensive so the SSIS logic would be a headache. The ADO.Net approach is the direction I’m leaning as data readers, bulk inserts and LINQ should do the job nicely. However considering how many people this must have effected before me I’m thinking there must be a better way. What approach do you guys use?

To get a bit more specific the details are:

• SQL Server 2008 R2
• ~2 million rows over roughly 30 tables -> ~20
  tables
• Databases will each be on completely separate database servers
  with different credentials

Many thanks

Answer 1

Lets supose this scenario:

S_old: your 'old' server
S_new: your 'new' server
db_old: your 'old' database
db_new: your 'new' database

A solution may be a nighly db_old backup and restore from s_old to s_new: db_old_bk. Then, in s_new you have access to both databases (db_old_bk and db_new) At this point you can do upserts with ‘merge’ sqlcommand on t-sql easyly (we are talking about 20 tables). Is this that you are looking for?