Hello. As I understand it, this utility outputs a deploy script to aid in creating/updating the database. Are the inter-dependcies of database objects taken into account when outputting these commands? In other words, are the invocations of the individual scripts made in the proper order? For example will parent tables always be created before child tables, or at least will the parent table always get created before its child table foreign key relationship?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This utility will deploy a set of files in a sequence which accounts for most dependencies. It does not actually create a separate "deploy script." But here is how it works.
Review the document titled "Visual SourceSafe Guidelines". Whether you use VSS or another source management tool, the objects of the project should be retrieved for deployment. That document describes a technique whereby only the objects of the project are retrieved. [This differs from some commercial tools which produce a change script by comparing 2 databases.] Now, with the objects to be deployed in the proper filesystem tree, the "Deploy.cmd" command file will execute each of these files in an appropriate sequence.
As for table dependencies, it should be noted that files with a CREATE TABLE statement will have nothing other that the table itself. The table's keys [primary, unique, foreign] as well as its indexes, triggers and default/check constraints are each in their own individual file. Therefore, the sequence in which the tables are created are irrelevant -- they have no dependencies until after foreign keys are added. So, when in the deployment sequence it is time for tables to be processed, ALL new tables are created, followed by any ALTER TABLE's, DELETE's INSERTs and UPDATE's; this is followed by adding all primary and unique constraints, and this is followed by adding all other indexes. Only then are the foreign keys of the tables added. So you see that there are no dependency issues in deploying tables.
Now, one area where a purist might take offense is in the deployment order for stored procedures. Stored procedures are deployed alphabetically [by filename]. If procedure A calls procedure B, a "can't add rows to sysdepends" warning will be issued, but the procedure will still be created. I have no problems with this issue, but if it matters to you, then you can make a special version of "Deploy.cmd" for the deployment, and manually code to make sure certain stored procedures are processed prior to the alphabetical list.
Hope this helps.
Richard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello. As I understand it, this utility outputs a deploy script to aid in creating/updating the database. Are the inter-dependcies of database objects taken into account when outputting these commands? In other words, are the invocations of the individual scripts made in the proper order? For example will parent tables always be created before child tables, or at least will the parent table always get created before its child table foreign key relationship?
Thanks.
This utility will deploy a set of files in a sequence which accounts for most dependencies. It does not actually create a separate "deploy script." But here is how it works.
Review the document titled "Visual SourceSafe Guidelines". Whether you use VSS or another source management tool, the objects of the project should be retrieved for deployment. That document describes a technique whereby only the objects of the project are retrieved. [This differs from some commercial tools which produce a change script by comparing 2 databases.] Now, with the objects to be deployed in the proper filesystem tree, the "Deploy.cmd" command file will execute each of these files in an appropriate sequence.
As for table dependencies, it should be noted that files with a CREATE TABLE statement will have nothing other that the table itself. The table's keys [primary, unique, foreign] as well as its indexes, triggers and default/check constraints are each in their own individual file. Therefore, the sequence in which the tables are created are irrelevant -- they have no dependencies until after foreign keys are added. So, when in the deployment sequence it is time for tables to be processed, ALL new tables are created, followed by any ALTER TABLE's, DELETE's INSERTs and UPDATE's; this is followed by adding all primary and unique constraints, and this is followed by adding all other indexes. Only then are the foreign keys of the tables added. So you see that there are no dependency issues in deploying tables.
Now, one area where a purist might take offense is in the deployment order for stored procedures. Stored procedures are deployed alphabetically [by filename]. If procedure A calls procedure B, a "can't add rows to sysdepends" warning will be issued, but the procedure will still be created. I have no problems with this issue, but if it matters to you, then you can make a special version of "Deploy.cmd" for the deployment, and manually code to make sure certain stored procedures are processed prior to the alphabetical list.
Hope this helps.
Richard