People care about their data. When I’ve been hired to develop custom applications, one topic that always arise is where and how the data is stored. Some customers even wanted a full database description, especially those that have IT departments.

The process to document a database is a time-consuming task. You can start documenting a database as soon as you add your first table or you can defer this task to the end of the project.

The first approach has some advantages. First you have updated database documentation for your own use and you only have to waste little chunks of time to keep it updated. At the end of the project you are done! However, those little chunks of time slow down the coding pace.

On the other hand, documenting the database at the end of the project can be a long task and you must be free to fix those last bugs that shipped with your app.

The solution to this problem is obviously to automate this task. SQL-92 compliant databases provide a mechanism to retrieve information about database schemas. They provide different views under the name of INFORMATION_SCHEMA, so you can perform classic ‘SELECTS’ to get table names, field names, indexes, etc. Unfortunately you can’t extract comments using this method. Instead you are forced to dig into the inner workings of the system tables to get them.

I developed a simple command-line tool to do the dirty job and I published a small article in CodeProject about it called SqlDoc. Since then this tool has been very useful to me. I added support to other database engines that I needed: Firebird and Access.

SqlDoc evolved to my first commercial product: dbdesc.