Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: Automatically altering tables from different schema's

by mpeppler (Vicar)
on Jan 08, 2004 at 16:41 UTC ( #319855=note: print w/ replies, xml ) Need Help??


in reply to 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
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

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://319855]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (8)
As of 2014-12-26 16:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (171 votes), past polls