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.

Some of my procedures are missing from the output, why?
When the project starts processing, my CPU goes to 100% for a rather long time, and task manager shows it as not responding. Why?
I get "Runtime Error 53, File Not Found" after I press Finish.
My procedure returns only one result set, but SQLHelp lists more than one, why?
I have a procedure that returns information via SELECT *. Why do I not see the column names?
I have joins that return the same column name from multiple tables, but SQLHelp only lists the column name once.
My procedure returns a result set from a nested procedure. How can I get that result set to be included?
I run SQLHelp against my files, but get no output. Am I doing something wrong?

Some of my procedures are missing from the output. What could be causing this?

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.

Back to Top

My CPU goes to 100% when I start processing a project.

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.

Back to Top

I get "Runtime Error 53. File Not Found" after I press Finish.

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.

Back to Top

My procedure returns only one result set, but SQLHelp lists more than one, why?

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.

Back to Top

I have a procedure that returns information via SELECT *. Why do I not see the column information?

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.

Back to Top

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.

Back to Top

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.

--##OV
--##BD We are using a nested procedure here
--##RS1 UserName ^^ The user's name
--##RS1 Address ^^ The user's address

Back to Top

I run SQLHelp against my files, but get no output. Am I doing something wrong?

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:

SQLHelp parses the SQL batch looking for SQL procedures, specifically the CREATE PROCEDURE directive. If this directive can not be found, SQLHelp will conclude that the batch does not contain a procedure to document.
Prior to SQLHelp 1.6, if the batch did not return data, modify data, perform work in a transaction, use a cursor or execute a sub procedure, then it would not be included. Beginning with SQLHelp 1.6, these procedures will now be located in the Uncategorized grouping.
If in the same batch (i.e. in the same text area containing a GO statement, or the entire file if no GO is found), a drop for the procedure was found, then SQLHelp 2.0 will first parse the procedure adding it to the project, then parse the DROP and remove it. To resolve this issue, ensure that all CREATE and DROP statements are contained in separate batches.