Feature request: Saving scripts in seperate files

obkobk Posts: 2
edited December 20, 2005 9:13AM in SQL Compare Previous Versions
Normally when using Sql Compare, one selects the objects to synchronize, click the Synchronize button and either exec the synchronization, or save it as a script.

That's an okay approach when dealing with new objects, no problem.

But when it comes to upgrading tables, I often run into trouble.
Let me illustrate that with an example:

In a current version of a database, I have a table called Action. There are already several rows in the Action table.
I've decided to categorize the data in the Action table, by adding a new table called ActionType in my database, altering the Action table by appending a new column called IdActionType. This is a new foreign key to the Id field of ActionType table.

So far so good. But to keep integrity, I want Action.IdActionType to be a NOT NULL field and surely creating the foreign key constraint.

Now, that's a problem, Sql Compare can't do this kind of thing. If I try to synchronize this, an error will be thrown, because I add the new NOT NULL field.

Instead I split the upgrade up in different scripts, which are run separately in these steps:

1) Create new table ActionType (by using Sql Compare)
2) Add data to ActionType (some kind of handmade script)
3) Alter table Action (by using Sql Compare)

Note that I have to alter the script in 3) a bit, to insert values in field IdActionType that does not violate the foreign key constraint.

Okay, long story, here's my point:
I have to manually select the tables to alter one by one in the Sql Compare UI, to save a script for each table.
And that is, to be honest, very tedious !

Instead I would like to have a feature in which I'm able to decide if I want one large script, or one script for each object.

Thanks in advance.

Comments

  • obk wrote:
    Instead I would like to have a feature in which I'm able to decide if I want one large script, or one script for each object.

    Thanks in advance.

    Hi,

    unfortunatly in the cases of many objects (especially with Yukon ones) in order to modify a single object we need to do a lot of modification on other objects. For example to modify a single XML schema collection in certain cases one must drop and recreate message types, services, event notifications, functions, and unbind and then rebind to tables. If more than one object is involved the rebuild actions affect each other and it is almost impossible to separate the various actions from each other.

    Regards,
    Andras
    András Belokosztolszki, PhD
    Red Gate Software Ltd.
This discussion has been closed.