January 20, 2009 at 9:29 am
We have a business running nursing homes and we keep all of our data about them, addy, phone, city, codes, and other important stuff in two tables.
I am migrating some databases to the new server and just putting them all on the same machine. I'd like to be able to use the two tables from the AppProd database in the Legacy database.
Should I copy the two tables over to the new DB? I was thinking of doing that but if changes are made to the AppProd tables, I would need them to copy the new/updated/deleted rows to the Legacy db as well.
I thought I would set up the main tables with triggers to send inserts/updates/deletes to the Legacy db whenever things change in AppProd.
Am I doing WAY too much work, or does that sound feasible?
January 20, 2009 at 9:37 am
SOP for this is to use SQL Server Replication to replicate the two table from the new server to the Legacy server/DB as read-only tables there.
There are a lot of other options and ways to go, but that is where I would start to determine if it fit or not.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
January 20, 2009 at 9:42 am
Thanks man, I'll look into that further, but I thought replication was a 2008 technology. I'm a developer who's being forced to be the dba as well 🙂
January 20, 2009 at 9:50 am
Nope, replication has been around for quite awhile. I think I first "played" with it to see how it worked in SQL Server 7.0 but I never went beyond the investigation stage myself.
I am sure it has improved over the years. SQL Server 2005 introduced peer-to-peer replication.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply