SQL Doc project files.
david connell
Redgate › Posts: 172 Silver 1
The SQL Doc project files.
Please note that if you incorrectly edit this file directly you may not be able to document your database again using this project file. The structure documented here maybe altered in future versions of SQL Doc.
The project files for SQL Doc are outputted in XML and has the following structure
As you can see the basic structure is based around a Project which has several attributes. Each Project consists of Items and ObjectExclusions (objects excluded). The Items itself is a collection of databases which in turn have a collection of objects.
In this document I will only describe the attributes for the Project.
SQL Doc 1.0 Features
Author-Name of Author
Copyright-Copyright details
URL-URL link
HtmlPath-Path to the generated output
ProjectDescription-Description of the project displayed on the front page
Treeview-Specifies if to generate a tree view or not
OutputStyle-StandardHTML/FramedHTML/ CompiledHelpThe generated format
Server-the default Sever name
Database-the default Database name
IntegratedSecurity-True or false
Username-The user name if not using integrated security
paswword-The password for the username
AllowEditing-True or false enabling the editing of the descriptions
ApproxVals-Number of database objects
Forced-Over-write previously generated output
SQL Doc 1.1 Features
IncludeSQLScript-Include SQL Scripts in generated output
IncludeTriggers-Include Table/View Triggers in generated output
IncludeIndexes-Include Indexes in generated output
IncludeForiegnKeys-Include Foreign Keys in generated output
IncludePermissions-Include Permissions in generated output
ThemeName-The name of the theme. The name must match the folder name under %Program Files%\Red Gate\SQL Doc 1\Style1\Skins
NewDatabaseObjects-Enabled/Disabled. Specifies if new items to this documentation are automatically enabled or disabled.
SQL Doc 1.2 Features
Please note that if you incorrectly edit this file directly you may not be able to document your database again using this project file. The structure documented here maybe altered in future versions of SQL Doc.
The project files for SQL Doc are outputted in XML and has the following structure
<?xml version="1.0" encoding="utf-16"?> <Project Database="WidgetStaging2005"> <Items> <Database > <Objects Object0Name="..." </Database> </Items> <ObjectExclusions> <ObjectExclusions Exclusion0="..." </ObjectExclusions> </Project>
As you can see the basic structure is based around a Project which has several attributes. Each Project consists of Items and ObjectExclusions (objects excluded). The Items itself is a collection of databases which in turn have a collection of objects.
In this document I will only describe the attributes for the Project.
SQL Doc 1.0 Features
Author-Name of Author
Copyright-Copyright details
URL-URL link
HtmlPath-Path to the generated output
ProjectDescription-Description of the project displayed on the front page
Treeview-Specifies if to generate a tree view or not
OutputStyle-StandardHTML/FramedHTML/ CompiledHelpThe generated format
Server-the default Sever name
Database-the default Database name
IntegratedSecurity-True or false
Username-The user name if not using integrated security
paswword-The password for the username
AllowEditing-True or false enabling the editing of the descriptions
ApproxVals-Number of database objects
Forced-Over-write previously generated output
SQL Doc 1.1 Features
IncludeSQLScript-Include SQL Scripts in generated output
IncludeTriggers-Include Table/View Triggers in generated output
IncludeIndexes-Include Indexes in generated output
IncludeForiegnKeys-Include Foreign Keys in generated output
IncludePermissions-Include Permissions in generated output
ThemeName-The name of the theme. The name must match the folder name under %Program Files%\Red Gate\SQL Doc 1\Style1\Skins
NewDatabaseObjects-Enabled/Disabled. Specifies if new items to this documentation are automatically enabled or disabled.
SQL Doc 1.2 Features
Comments
Any plans to remedy this?
(Also foreign is spelled incorrectly (foriegn) )-: )
Thanks for your post. At the moment, we are not planning on changing the project file format.
I am interested in hearing why you would like a schema for the project file? Is there anything particular you would like to be able to do?
Thanks
Ben
In this post you publish a 'description' of the xml file. IMO Normal practice would be to publish the schema.
Among the benefits of the schema approach is that if you do make modifications to the xml and it subsequently doesn't work, you can validate against the xsd schema, and often this will tell you where you've broken it. (Depending on the tool, you may also benefit from intellisense etc..)
But basically I just find it a very bizarre design choice, which is hard to explain.