Object Type Filters
Just as the server object filter filters server objects, the database object filter allows you to filter the previously selected database objects based on object name, schema or regular expression, if you didn’t select the object in the Object Type step, it will be grayed out here.
Checking a “use filter” check box here will also add an additional step to the Graphical Treeview.
In this step you can choose which database level information to include in the documentation. Some options which fall under this category are:
- Database summary information
- DDL Options
- Table of contents groupings, sections can be included using the following groupings:
- Objects by Filegroup
- Object by Owner
- Whether columns and parameter dictionary should be included
I’d like to draw your attention to the Extended Properties settings.
And this brings me back to the description I pointed out to you earlier in the snippet from the procedure documentation. That description has been saved in the database as an extended property. Using extended properties is a good way to explain your database structure and objects to people without having to depend on additional documentation, and what’s great about ApexSQL Doc is that it not only extracts these properties and adds it to your documentation, but with the new Customs Description Editor (which I will cover a little later on), Doc also helps you to add these descriptions to the database.
If you are using extended properties and you do want it to be included in your documentation, you have to specify it here.
You also have to select which extended property name ApexSQL Doc should look for. The default name is MS_Decription, but you can create your own extended properties name.
Database Dependency Options
If you want to include the various relationships between your objects in your documentation, ApexSQL Doc provides you with 2 options. You can simply include Parent and Children lists and tables which will be included on the specific object page in the documentation like this:
Alternatively you can select to “Explicitly parse the database for improved dependency accuracy” which then also enables you to include “Graphical Dependencies” in your documentation.
I personally quite like this feature as it makes your documentation look so much more presentable, which always impresses management 😉
This is what this would look like in your document.
As you can see here, the table HumanResources.Department depends on the Object Type Name which is a customized data type, and it in turn is depended on by two views which selects from it (depicted in green) and by another table HumanResources.EmployeeDepartmentHistory which has a foreignkey dependency on HumanResources.Department.
Performance Intensive Options
While specifying the options you wish to include, you might have unwittingly included some options which are considered performance intensive. ApexSQL have inserted this Performance Intensive Options step, to highlight these options and allow you to review it prior to commencing the compilation of the documentation.
One such option is the “Explicitly Parse Database for Improved Dependency accuracy” option, as well as the “Graphical dependency” option which we have just discussed. So should you wish to include that, you must take note that creating the documentation will take some additional time, having said this however, this new version of Doc has definitely optimized its performance in this regard.
Integration Services Details
For each SSIS package you have added as a data source you can choose to include the following in the documentation:
Each of these items will appear as a node in the documentation table of contents, and depending on whether the particular item has been configured in your package you will be able to drill down on each to the most granular level.
The table of content might look like this:
Each property and element will be extracted and placed into the documentation like this:
Or like this for elements: