Third Party Products
SQLHelp Runtime Issues
The issues listed here are specific to SQLHelp. If you do not see the issue you're facing addressed, it may be addressed in the general section, or it may be new to us. If after checking the general section, you still don't find a resolution, please drop us an email, with as many details as possible.
When SQLHelp 2.0 and higher (and DBDocumentor) process a script file, the SQL parser will break the script into individual batches. The breaking point is a GO directive. If no GO is found in a script file, the entire file is treated as a single batch. Neither the SQLHelp nor the DBDocumentor SQL parsers process the file sequentially, rather they process each batch sequentially and look in each batch first for CREATE statements and then for any DROP statements. If a DROP statement is present for an object already present in the project, the object is dropped.
If the DROP for an object is present in the same batch as its CREATE, then SQLHelp and DBDocumentor will add and then remove the object from the project, creating the scenario of missing procedures for SQLHelp and missing objects for DBDocumentor.
To work around this issue, ensure that if a DROP is present in a script file for an object you wish to have documented, that the DROP is contained in a batch occurring prior to the CREATE.
It is not uncommon for a computers CPU to go to 100% for a period of time when heavy work is being performed. In the case of SQLHelp and DBDocumentor, this will happen on virtually all classes of CPU regardless of processor speed when a file is first loaded, and only when a file is first loaded. If your SQL project is made up of a single file containing all the script batches of your database, the length of time the CPU is at 100% will be longer. If a file contains a single script, the period of time maybe undetectable.
During file load operations a number of sanity checks are performed on the file and the larger the file, the greater the number of checks. It is also possible that Task Manager will report the SQLHelp or DBDocumentor process as not responding.
By way of example, if a single file is used to contain a database of 50 tables and their indices, with approximately 400 stored procedures for these tables, and all the associated DROP statements and default data, this file will take between 10 and 15 seconds to load on a Pentium IV class machine. If this same file is broken into many files with each individual file containing a single SQL object, the load time is not noticeable.
For DBDocumentor, this problem was resolved in version 2.31. For SQLHelp users this problem was resolved in version 2.20.
Note: This error is resolved in version 1.4 of SQLHelp. If you do not have version 1.4 or higher, please download it here.
This error indicates one or more configuration files are missing. If you receive this error, first try reinstalling the SQLHelp, and if that fails, send a file listing for the installation path where SQLHelp is installed to support. By default, this location is Program Files/SQLHelp. We will determine which file is missing, and send you an update.
This is by design. It allows you to ensure that the format of the result sets is the same. If differences are noted, this could pose a problem to the consumers of this procedure.
This is due to the disconnected nature of SQLHelp. Since SQLHelp does not make use of any database connectivity, it is not able to determine the column names belonging to the underlying table. From an interface design perspective, you may wish to consider redefining the procedure to return only named columns.
I have joins that return the same column name from multiple tables, but SQLHelp only lists each column name once.
SQLHelp version 2.0 and higher no longer has this problem. It should be noted that consumers using ADO and procedures having multiple column names of the same name may experience difficulties in accessing your procedure.
My procedure returns a result set from a nested procedure. How can I get that procedure to be included?
Currently the only method to accomplish this is via the override tag. You would need to include the parameters of the nested result set in the upper level procedures' documentation, then use the override tag in the upper level procedures' documentation. e.g.
There are a number of reasons why no output might be returned. For the purposes of this discussion, it will be assumed that SQLHelp runs to completion with no obvious errors and a compiled help file is produced. This help file would contain only an overview section. Some of the reasons for this situation include:
© 2001 - 2004 Pikauba Software. All rights reserved.