Re: Automatically altering tables from different schema's

I haven't seen anything like that before, and there have been times when I could have definitely used something like it!

If I were to write that sort of tool, I would probably try to use the table definitions as returned by the database servers themselves rather than a SQL script, as the database servers will return the data in a more regular fashion (easier to parse), and in some cases (e.g. Sybase) you don't have to parse anything at all, you just query the system tables and get the necessary data.

Second, I would not go and directly update the target database. Instead I'd create a SQL script that has the ALTER TABLE statements so that it can be checked, and that the update operation is run in a controlled manner.

Michael

Comment on Re: Automatically altering tables from different schema's

Replies are listed 'Best First'.
Re: Re: Automatically altering tables from different schema's by liz (Monsignor) on Jan 08, 2004 at 16:54 UTC
Instead I'd create a SQL script that has the ALTER TABLE statements so that it can be checked, and that the update operation is run in a controlled manner. I'm going for ease of use, so any changes would be "automatic" (with maybe the option of not deleting columns automatically). But there would be an API to get at the primitives, so that you can indeed do what you propose. Liz	[reply]
Re: Re: Re: Automatically altering tables from different schema's by monktim (Friar) on Jan 08, 2004 at 17:40 UTC
Liz, That is exactly what we do at my place of employment. We keep a text file with a list of tables that have changed. Our script gets the tables from source control (CVS) and then parses the table file (i.e. Table1.TAB) for column names. If the column name doesn't exist on the destination, an ATLER TABLE command is executed to add the missing columns. Our updates are done directly to the dB. If you do it directly to the dB like you want or you choose to output to a SQL script like mpeppler suggested, you'll probably want to make sure that either way the script(s) are re-runnable. It is not often that we DROP or modify columns. For me, this has to be done another way. Our DBMS repication can't handle column DROPs or UPDATEs without intervention.	[reply]


P is for Practical
	PerlMonks