David, very nice! Of course, it all comes down to someone putting in the descriptions for each field or you just get a list of tables and columns.

I'd be interested in knowing how many DBAs/Developers take the time to actually fill in the descriptions. It would also be very interesting to see how many do this for commercial systems where the client requests a data dictionary vs. internal systems that are only used in house.

I'm part of a project developing an application for states to use when managing various programs. As such, we have to provide a data dictionary as part of the deliverables, but some of the descriptions the developers supplied are things like "this is the ID field" or "disscribs the person" [sic]...Not helpful and not accurate, and shows that, sometimes, developers aren't the best at using English! I created an Excel/VBA tool to pull the table names from the database, create a tab for each table and populate the new worksheet with table and field names, and also the extended properties for each. At each milestone in the project, we deliver the Excel file to the documentation department for "wordsmithing", then another button on the Excel file updates (or inserts) the MS_Description property in the master database. Quick, easy, adapts to changes in the tables, and allows the developers to concentrate on writing code, while the documentation folk get to do what they get paid for.

The only hiccup in your detection of blank extended attributes is when the developer uses "Must populate this" as their description for each and every field in the tables they create!

Personally I think the data dictionary approach would be better served using a data modeling tool like Toad Data Modeller or Rational Rose. (I use Toad myself).

That way not only do you have the tables laid out graphically, showing relationships, you also have the comments for each table and field, plus any functions, and if you use the built in domain tools you have consistancy across tables for things like zip codes, phone numbers, etc.

Since I wrote a small Access tool to generate the basic stored procedures and it has the ability to let me create more complex SPs myself (along with notes, etc) I find I don't rely so much on SQL Server for documentation.

IMO a dedicated data modeller is the most logical place for documentation anyway, since it basically is both documentation *and* script creation tool.

Dennis Wagner-347763 (2/17/2011)It would also be very interesting to see how many do this for commercial systems where the client requests a data dictionary vs. internal systems that are only used in house.

At my company, we force application developers to submit database requests with descriptions for the objects. This is enforced through the intranet page where they submit the request. Additionally we review the descriptions to make sure they make sense!

The extended properties are released to all of our customers. We also use these properties for an internal data dictionary as well as an external data dictionary that our customers can view by logging on to our customer support web site. Even though the information is in the customer's database we provide the information on the web site for those customers that aren't familiar with getting the information through T-SQL in the database.

Good article. I am writing some .net code to manage SQL Server Extended Properties across all our servers including managing different 'sets' of extended properties, bulk copying and pasting of properties from database to database, table to table and even field to field.

Its likely to be a few more weeks in production but I can put some details up if I get it running. It doesnt hold properties in a table though, they are dynamically queried.