Part of the automatic update distribution app I wrote for Feds. Initially it did both fox's dbf files and the SQL database, then after 5.3 we ditched the dbfs.
The whole trick is that for each change in the database, the regular way is to write a transition script from version n to version n+1. However, that requires a lot of manual housekeeping, strict versioning, and above all knowing which customer is on which version, then distributing a package of all m intervening scripts from version n to n+m, because almost every Firriver's clinic would skip many versions between updates.
To avoid that, I took a snapshot of metadata defining the current (target) version of the database, and packaged these metadata with the updater. When running on a target database, it would take same metadata of it, compare with the packaged ones, and build a series of statements to bring the target db to the state as described in the package. It would change the width of a column, add a column, add a default, add a trigger, add a stored procedure or function, add a table, index and perhaps a few more details.
This got me into trouble with admins in a few places, where they wanted to see the transition script in advance, so I had to explain the mechanism and why the script doesn't exist in advance but is built on the spot.
This piece, along with the rest of the update builder, has saved us a lot of time over the years, and made the build process automatic. Previously, the update process had 18 steps which had to be performed in strict order, on the spot, over whichever connection was available. Now the creation of a new build would take between 2 and 5 minutes, and the installation at the target would take no brain but just the time it took to transform the tables.