December 7, 2002 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/buildingademoserverpart2.asp
December 12, 2002 at 6:58 am
You make some good points, but I don't see a workable solution for a database where many tables must be kept in sync. I was thinking that possibly replication might work as you pointed out, but there are just too many variables to consider in my case.
The only workable solution we have come up with to this point is to keep a demo system totally segregated from a production system. This puts the onus on the person in marketing to keep the database up to date. The problem with this solution is that when permanent data or schema changes are made, these changes must be backed up so the database can be restored to this point after sales and marketing people set things up for particular demos.
There just does not seem to be one good solution for everybody. But, we keep looking for improvements.
Thanks for the good article. Keep them coming.
LarryC
December 12, 2002 at 9:44 am
Not a great solution presented, I'll admit. Mainly because I couldn't come up with one. I started the articles while working on this project and never got a good solution.
What worked best (for limited tables, like the product structure) was to have the client tools make changes to both servers. The user could add the product to the QA (test) server. Then "copy" it to production and demo with one click. Not a great solution but worked good in limited places.
Replication was ok, but with lots of parent-child-grandchilds, it failed.
Complete separation was ok, but usually ends up with some double data entry to get things somewhat in synch for inventory,products,salespeople, etc.
Sorry I couldn't come up with anything, but thanks for the comment.
Steve Jones
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply