First of all, thank you Jack for the terrific SQL:SQLTESTx programs. You have taken practically all of the effort out of writing programs to create and access SQL tables.

In running SQLTEST4 as well as my own variations of that program, I continually get error 29 (in cmdhdr.rc) when executing the Close Library function. I cannot find what that error code signifies (on a MySQL close) and it doesn't seem to cause any subsequent errors (except on the next close).

This happens with two different databases, including the sample "sakila" db.

Does anyone have any idea what this error means? Should I just ignore it?

Just on a whim, I logged out of A-Shell and then back in. I reran my program and this time, there was no error. So I am chalking it up to a temporary glitch.

Thanks for the feedback.

Actually, error 29 is defined in SQL.DEF as:

But the SQLTEST4 program is using an older version of the error message function - Fn'AshSQL'Error'Descr$(rc) - instead of the newer one Fn'SQL'ErrMsg$(cmdhdr) in the sql:fnsqlerr.bsi module. That's why it wasn't getting reported. (I'll put it on the list of things to update!)

The SQLERR_NESTIGNORE status is returned from the SQLOP_CLOSE_LIB when there have been more SQLOP_INIT_LIB calls than SQLOP_CLOSE_LIB calls. This can occur when a program or SBX is unaware of the global init status of the library and issues its own init in order to perform some SQL operations. In that case, when it issues the close operation, we don't really want to close the library for the entire instance of A-Shell. So instead, it just returns this code.

In some contexts (like a global cleanup utility, you might want to detect that status and keep issuing SQLOP_CLOSE_LIB calls until you stop getting that status returned (i.e. to fully close the library). But in most cases, one wouldn't bother with that, since you can just exit the A-Shell instance to fully disconnect the library (like you did).

I'm not sure why you got that condition with the SQLTEST4 program, but if you think it is a recurring/repeatable case, let me know and I'll investigate. But more likely, it was just a result of some aborted testing scenarios.

I'll talk to Ty about updating the documentation...

I'm sure the problem was due to aborted testing scenarios. I need to update my programs to trap and close SQL on ^C.

We added more error codes and a variety of notes to the documentation, so everything is up to date. Here's the page with the expanded list of error codes.

I don't see any updates to that page, Ty.