I suspect the note about nested triggers in the article is stating that one trigger cannot refer to another trigger - it is implicit by performing an action against another table.  Thus, as you eventually state, the order of creation of triggers is unimportant and each trigger is unaware of the presence of other triggers on the tables.

I was interested to read this article as I had recently finished building my own auto update utility for updating client's databases to the latest version.  I have taken a very different approach...

Each time I create a table, modify a stored proc, etc I save the code executed by enterprise manager (if modifying tables on the database diagram) or the ALTER/CREATE statement from query analsyer in a file on disk.  Also, any DML that I need to execute on the database (such as populating some default data for a new column) are also saved as a script file.  The files are organised into folders as such

Scripts /

   20060401/

   20060403/

   20060410/

Thus the changes made to the DB in a version - I use the current date as the version number - are all stored in the folder.  The filenames of the scripts are unimportant - but their timestamps are important as this ensures they can be executed in the correct order.  The names of the folders should also appear in a sorted order - hence the YYYYMMDD naming convention - the folder name is used as the database version identifier.

Once I wish to close off a database version, I simply open a command prompt, go into the folder (eg Scripts/20060410) and type

dir *.sql /b /od > DoxScriptFiles.txt

This creates an ordered list (by file timestamp) of the SQL script files to execute.

The entire scripts folder is always shipped to customers so all scripts to upgrade from any DB version are included.  I have a batch file + SQL server script which

a) determines the current version of the customer's database by examining the databaseVersion table

b) performs a backup marked with the current timestamp and the current DB version

c) Executes the scripts in each folder one by one - the folders, named as they are, ensure the the versions are applied in each order.  The scripts to execute in each folder are read from the DoxScriptFiles.txt text file - again to ensure they are executed in the correct order

d) A versionUpgradeDetails table stores the date and time of each script execution as well as the complete text output

e) After each script is executed, I check the output for any error messages

f) As each version's set of scripts is successfully executed, I add an entry to the databaseVersion table.

If an error occurs, I inform the user and then perform a database restore.  If no errors occur, all is well.

I have adopted this approach because

a) I personally save all change scripts so it is no extra work for me

b) There is a readily available audit trail of changes made to the database

c) It allows me to ship out the latest binaries of our software as well as the same database upgrade scripts.  The customer needn't know what version of the database / binaries they are running - the "upgrade Dox" batch file takes care of determining the version and executes the scripts in the correct order as I made them - this ensures all dependencies are accounted for.

If anyone's interested I can post the code for the batch file and the accompanying SQL script file (which does most of the work of looping through the folders and executing the scripts).

It's a different approach which may have its drawbacks but it is much easier to deploy and doesn't require any extra processes during deployment to determine dependencies, etc...

My 2c - but anyhow, it was a very good article - very thorough and nice to see another point of view on the topic

Cheers