Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
JohnCullison
Starting Member
1 Post |
Posted - 2010-07-02 : 14:42:06
|
Hi,I don't know if I'm in the right place or not, but I'm hoping someone here can direct me.As we upgrade our applications, we invariably add to the existing database schema and default data for various tables and need to deal with handling the upgrade process for existing installations. In the past, this has meant creating hand-tailored scripts which work only on one specific installation type/version. So, for example, we have a script to go from official 2.1 to official 2.2, and another to go from official 2.0 to official 2.1. This has been a problem for us when we've had slight deviations from "official" in the field.So what I am looking for is a tool that I can use which will take a snapshot of my latest and greatest database, and use that snapshot to analyze an existing database and make it match the snapshot, without clobbering the data which is already present. We also need to have our stored procedures analyzed and updated, and any views adjusted.So, two questions: 1) Is SSIS the tool for this? 2) Does anyone know of some 3rd-party tool which can do this?I'd like to be able to run whatever it is as part of our installer (not in the MSI but as part of our master installation EXE).Thanks!=-John-= |
|
Kristen
Test
22859 Posts |
Posted - 2010-07-03 : 01:38:16
|
Red Gate (and probably others) have a Database Compare tool which will compare two databases and generate a script to get from A to B.You could have a data-empty copy of your system that you restore to a client's server, script the differences with DB Compare, and then upgrade the client?You probably have some data changes too? that's a bit more difficult to do - DB Compare will script that too, but you aren't exactly comparing like-with-like.Dunno what your application is, but we script all DDL changes to sequentially numbered "version" scripts, and any data updates ("UPDATE to Y all customer who have X" type stuff) are in those too.We have each Sproc and Trigger in separate files, and we ship those based on change-date-since-last-releaseAnd then we have some Meta Data which is more difficult - some data the client can override, some they can't, and that all has to be built into a script which will work for all clients.We don't allow clients to have off-version DDL (they have to upgrade to a version compatible with what they want ) but we do allow off-version Sproc / Trigger updates - and they just get overwritten at the next formal rollout. |
|
|
|
|
|
|
|