Update Subscriptions
 |
DBDocumentor produces database documentation for the various SQL objects in your database, and any Microsoft SQL Server Reporting Services RDL reports accessing the database. The list of SQL objects documented varies with the SQL dialect chosen, and DBDocumentor currently supports; Microsoft SQL Server 2005 and below, Firebird 1.5 and 2.0, and Sybase SQL Anywhere 10 and below. Since Reporting Services can use any ODBC or OLE DB data source, reference documentation can be generated for for all DBDocumentor supported SQL dialects. There are several immediate benefits to documenting the SQL database and RDL reports as a single project.
Report and schema dependencies are clearly indicated
Report data access is clearly indicated, and as a result be managed
Report conventions such as stored procedure and transaction usage or limiting data modifications can be validated
Generating reference documentation for RDL reports and the associated SQL database using DBDocumentor is as simple as selecting the SQL dialect, selecting "Reporting Services RDL" as one of the SQL object types to include and specifying the RDL source files to process. Producing a report of only the Reporting Services components takes only a few minutes, but the real value comes when you also include the SQL source files for the database. The resulting combined documentation contains a fully cross referenced view of the SQL database and the Reporting Services reports, including where data is sourced from and what objects are modifying data in what other objects. The cross referencing extends to procedure and security usage, clearly showing which procedures are used where, and under what security context. These capabilities make DBDocumentor ideal for those wishing to learn the structure of a given database, how specific reports interact with each other, or simply to document the database and/or reports for future reference.
Extended capabilities of the rich feature set include declarative object grouping, support for DBMS metadata based descriptions like those provided in SQL Server Enterprise Manager or SQL Server Management Studio, SQL dialect specific syntax color coding, control over the documentation of temporary objects and dynamic SQL, ease of integration into automated build environments, and the generation of XML output. All documentation is generated by reading the source SQL batch files and requires no active database connection, or any database connectivity tools. The benefits of an offline SQL parser are many, and include the ability to document result set structure, return values and data access points.
DBDocumentor produced documentation is perfect as printed database application documentation for:
Client documentation for software development consulting projects
Online access for middle tier developers to develop against a documented database interface
Quality assurance efforts to ensure consistent coding guidelines are followed
Determining the degree of data exposure and risk by specific database functions and procedures
Determining the degree of dynamic SQL used in the database, and what data sources are impacted by the use of dynamic SQL
Determining what data is exposed via Reporting Services reports
DBDocumentor 4.50 contains new functionality and performance improvements. In response to customer requests, two specific items were added.
RDL documentation support has been added for SQL Server Reporting Services 2008 schemas.
The long awaited PDF output is now here. The PDF output shows a slightly different format from the normal HTML and CHM options, and this is mostly due to differences in how content is presented for these formats. As with the HTML/CHM options, all cross-referencing is present, and custom content is fully supported.
DBDocumentor 4.40 contains only new functionality. In response to customer requests, three specific items were added.
A major rework of the RDL documentation was performed. In previous versions, only the items directly relating to the SQL query used in a report element were documented. While this provided some value, there was no linkage between the various reports, nor was there any indication of where a given query was used within the report. These items have been resolved with the addition of report parameters, reports drilled into, reports drilled in from. Additionally, the report author is included.
The wildcard syntax for source file lists used in the external source file list was enhanced. It now supports partial match wildcards using the '?' character, and terminated partial matches using the '*' character. In both cases, the partial matching is on the file name, and follows standard Windows conventions.
Firebird 2.0 is now a supported dialect. All new functionality contained in Firebird 2.0 is supported, and automatically included in the updated output. All existing Firebird 1.5 projects are automatically upgraded to Firebird 2.0 projects, resulting in a seamless upgrade path for Firebird users. Please note that if you wish to take advantage of the new COMMENT syntax, you will need to enable that option in DBDocumentor.
DBDocumentor™ version 4.30 sees several major changes. The two most significant are changes in the supported operating systems, and major enhancements to a supported SQL parser.
Version 4.30 contains a significantly enhanced Sybase SQL
Anywhere (ASA) parser. Starting with version 10, Sybase has also changed its branding of
Adaptive Server Anywhere to SQL
Anywhere. DBDocumentor™ supports many of the new SQL Anywhere 10 constructs
including materialized views. The new keywords introduced with version 10
are also appropriately colorized.
In addition to the support for version 10, numerous enhancements were made
to the ASA parser. Some of the constructs now processed are:
Global temporary tables
Local temporary tables
The SET HIDDEN option on procedures, functions and views to encrypt them
Triggers defined on user specified tables now inherit the user of their parent table
If multiple create statements for procedures, functions or views were present in the same batch, DBDocumentor™ was only processing the first object in the batch, but was treating the entire batch as a single statement. When processing an Anywhere batch, DBDocumentor™ 4.30 is more statement aware and will correctly process most batches containing multiple create statements. The source code listing will continue to contain the complete source for the batch, not only the statements used in the create. In the event that multiple statements are in a single batch, to document them the syntax will need to follow that of ##FND.
DBDocumentor™ 4.30 now has official support for Windows Vista™ in all editions, including 64 bit (x64). When DBDocumentor™ installs on any Windows Vista™ operating system, you will be prompted with a digital signature dialog to identify that the installer is from Pikauba Software and the installer is for DBDocumentor. When you accept this dialog, you will then be prompted with a normal (gray) user access control dialog. If you are a local machine administrator, you will be able to accept this dialog and DBDocumentor will install. DBDocumentor has been tested and verified as fully functional on all versions of Windows Vista™. If you experience any problems with DBDocumentor on Vista, please let us know.
DBDocumentor version 4.20 is the first version of DBDocumentor to support Microsoft SQL Server Reporting Services. The following list details all the changes made for version 4.20 from version 4.10.
DBDocumentor now supports Microsoft SQL Server Reporting Services Report Definition Language (SSRS RDL) files. When defining a project, you have the option of including RDL files. If you choose to supply an RDL file to DBDocumentor, DBDocumentor will verify that the default XML namespace corresponds to either Reporting Services for SQL Server 2000, or SQL Server 2005 Reporting Services. If the default namespace doesn't match, the file will not be processed.
A change in the way XML was handled beginning with version 4.00 resulted in UNICODE entities being incorrectly handled and certain XML parsers would raise an error if UNICODE characters were present in the XML. This problem was only present in the XML output.
If whitespace appeared in a RAISERROR TSQL statement containing a textual error message, the text of the error message would be omitted.
If you specified an alternate (non default) file extension for your SQL source files, and then browsed to the location of the SQL source files, any files matching your alternate file extension would not be listed.
In TSQL, if a user defined function was called where there was an open bracket preceding the function name, without any whitespace, the user defined function was not listed as a called function. Now fixed.
The default CHM icon was being used for the content page icon. The standard CHM icon for a content page, by convention, is an icon depicting a page of paper. This has been changed. If the previous default icon is desired, please set the II tag on your content to a value of 9.
© 2001 - 2009 Pikauba Software. All rights reserved.
DBDocumentor and SQLDocumentation are trademarks of Pikauba Software.
All other trademarks are properties of their respective owners.
