Tomm Carr wrote: > From: "M.Francis" <[EMAIL PROTECTED]> > > > fyi, Erwin does allow this to be 'automated.' > > With user interaction the metadata in your erd is compared to that of the > > target database. > > When you perform a change in your erd and wish to forward engineer it > > to your database the tool determines the does a complete comparison with > > existing metadata to that of your erd or selected objects you chose to > implement. > > If the erd in ERwin contains triggers and stored procedures, then it can be > automated to a large extent.
The erd does not need to contain the triggers in order for Erwin to assist with the dependencies. The metadata in the schema is used to determine the current db objects' dependencies. > But ERwin can only generate a script of the > necessary ddl. A modification could very well need some dml. Agreed. But, one is allowed to set a default value for the column definition, or where one is not appropriate, modify the generated dml script with a work around of inserting an appropriate value to address the issue you've raised about the non-nullable column. This manual step is necessary thing because it is a judgement call made by the user as to what value is appropriate in those cases when a column does not have a default value setting. It would be odd to have a a modelling tool begin to perform data manipulation that are not part of the ddl construct. > > Consider the case of adding a column and the column is set to NOT NULL. > Before the contraints for the table are re-enabled, the column must be > populated with data. It may be a simple matter to manually insert the > necessary code into the generated script, but this just shows the > impossibility of ever *fully* automating the creation of the complete > script. I agree with the premise you had initially noted. It is difficult yes, impossible no. (It is resource/time intensive to come up with a matrix and a viable solution as well as maintain the same for future with unforeseeable changes ahead...) Still, wanting automation of data manipulation affected by ddl changes, is akin to expecting a data scrubber with a modelling tool. I'm not sure that's what the two functionally distinct aspects to be handled by the same tool. > > > The only drawback is that it leaves the old metadata and you have to do > > a clean up of the same.. > > If this was the only drawback, I would consider it a complete success. > I shall restate that-- [In the sequence of steps that I had outlined that Erwin follows the drawback is that it leaves the old/renamed tables/objects for one to manually clean up.] In responding to your initial comments, my point was and is, that there are tools that handle the basic needs in scripting, which you described as 'automated'. I did not mean to beleaguer the point, I apologize for the long email to say just this,- an automation of steps with decision points is viable when the many permutations are mappable to a matrix... cheers, M ____________________________________________________ To change your JDJList options, please visit: http://www.sys-con.com/java/list.cfm Be respectful! Clean up your posts before replying ____________________________________________________
