SQL Anywhere Feedback - Regularize and document ERRORLEVEL values

Author

Regularize and document ERRORLEVEL values

Breck Carter [TeamSybase]

2005-07-27, 1:24 pm

Please regularize and document the Windows ERRORLEVEL values set by
various command-line utilities; e.g., dbmlsync -k, dbspawn, dbsrv9 -a,
etc.

I believe that 0 means OK, 1 means some kind of failure, 5 means user
cancelled, etc., for dbisql and dbmlsync -k, but of all the .EXE files
that are delivered, apparently only dbisql settings are documented.

Some folks write sophisticated command files to invoke various
utilities, and it would be nice to know (a) that the ERRORLEVEL values
are reliably set and (b) what the different ERRORLEVEL values mean.

This request extends to dbsrv9 -a and dbsrv9 -f which are "batch
utility mode" uses of the engine, so the return code is useful.

Please note that over the years there have been *many* questions about
this topic in the newsgroups.

Breck

--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com

John Smirnios

2005-07-28, 9:23 am

Are the ones documented in sqldef.h insufficient?

#define EXIT_OKAY 0 /* everything is okay */
#define EXIT_FAIL 1 /* general failure */
#define EXIT_BAD_DATA 2 /* invalid file format, etc.*/
#define EXIT_FILE_ERROR 3 /* file not found, */
/* unable to open, etc. */
#define EXIT_OUT_OF_MEMORY 4 /* out of memory */
#define EXIT_BREAK 5 /* terminated by user */
#define EXIT_COMMUNICATIONS_
FAIL 6 /* failed communications */
#define EXIT_MISSING_DATABAS
E 7 /* missing required db name */
#define EXIT_PROTOCOL_MISMAT
CH 8 /* client/server protocol */
/* mismatch */
#define EXIT_UNABLE_TO_CONNE
CT 9 /* unable to connect to db */
#define EXIT_ENGINE_NOT_RUNN
ING 10 /* database not running */
#define EXIT_SERVER_NOT_FOUN
D 11 /* server not running */
#define EXIT_BAD_ENCRYPT_KEY
12 /* missing or bad encryption key */
#define EXIT_DB_VER_NEWER 13 /* server must be upgraded to
run db */
#define EXIT_FILE_INVALID_DB
14 /* file is not a database */
#define EXIT_LOG_FILE_ERROR 15 /* log file was missing or */
/* other log file error */
#define EXIT_FILE_IN_USE 16 /* file in use */
#define EXIT_FATAL_ERROR 17 /* fatal error or assertion
occurred */
#define EXIT_USAGE 255 /* invalid parameters on command
line */
/ ********************
*********/
/* exit codes 200 to 254 are */
/* reserved for internal use */
/* ********************
*******/

Breck Carter [TeamSybase] wrote:
> Please regularize and document the Windows ERRORLEVEL values set by
> various command-line utilities; e.g., dbmlsync -k, dbspawn, dbsrv9 -a,
> etc.
>
> I believe that 0 means OK, 1 means some kind of failure, 5 means user
> cancelled, etc., for dbisql and dbmlsync -k, but of all the .EXE files
> that are delivered, apparently only dbisql settings are documented.
>
> Some folks write sophisticated command files to invoke various
> utilities, and it would be nice to know (a) that the ERRORLEVEL values
> are reliably set and (b) what the different ERRORLEVEL values mean.
>
> This request extends to dbsrv9 -a and dbsrv9 -f which are "batch
> utility mode" uses of the engine, so the return code is useful.
>
> Please note that over the years there have been *many* questions about
> this topic in the newsgroups.
>
> Breck
>
>
> --
> SQL Anywhere Studio 9 Developer's Guide
> Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
> bcarter@risingroad.com
> RisingRoad SQL Anywhere and MobiLink Professional Services
> www.risingroad.com

Greg Fenton

2005-07-28, 11:26 am

Breck Carter [TeamSybase] wrote:
> Please regularize and document the Windows ERRORLEVEL values set by
> various command-line utilities; e.g., dbmlsync -k, dbspawn, dbsrv9 -a,
> etc.
>

This is an exact discussion going on in an internal thread with docs
right now. As you can imagine, there are more than a few people that
need to be queried to get all this info, but as John points out a good
portion of the error codes are in the .h file.

The big problem is actually a MS-Windows issue (no, really).

In most (good) operating systems, a 0 return code indicates success and
a non-zero (typically POSITIVE) value indicates a failure.

In MS-Windows script language, the code:

IF ERRORLEVEL 0 goto success
echo sorry, this failed
exit 1

:success
echo Woohoo!!!

will fail to detect errors with our tools because IF ERRORLEVEL <num> is
true if the exit code from the previous command is equal to or *greater
than* <num>. So when a tool returns a non-zero POSITIVE value, it
appears to be successful (in the above snippet).

There are at least two ways to avoid this (bad) behaviour:

IF NOT ERRORLEVEL 1 goto success
or
IF "%ERRORLEVEL%" == "0" goto success

(I tend to use the latter).

Hope this helps,
greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/

Breck Carter [TeamSybase]

2005-07-28, 1:26 pm

Thanks for the pointer... it tell me what individual numbers mean.

But it doesn't tell me what to expect from a particular program like
dbmlsync -k (that's what I meant by "document"), or whether a
particular program sets any code at all (I don't think dbsrv -a does,
and it should, which is what I meant by "regularize").

Breck

On 28 Jul 2005 07:11:36 -0700, John Smirnios
< smirnios_at_sybase_d
ot_com> wrote:
[color=darkred]
>Are the ones documented in sqldef.h insufficient?
>
>#define EXIT_OKAY 0 /* everything is okay */
>#define EXIT_FAIL 1 /* general failure */
>#define EXIT_BAD_DATA 2 /* invalid file format, etc.*/
>#define EXIT_FILE_ERROR 3 /* file not found, */
> /* unable to open, etc. */
>#define EXIT_OUT_OF_MEMORY 4 /* out of memory */
>#define EXIT_BREAK 5 /* terminated by user */
>#define EXIT_COMMUNICATIONS_
FAIL 6 /* failed communications */
>#define EXIT_MISSING_DATABAS
E 7 /* missing required db name */
>#define EXIT_PROTOCOL_MISMAT
CH 8 /* client/server protocol */
> /* mismatch */
>#define EXIT_UNABLE_TO_CONNE
CT 9 /* unable to connect to db */
>#define EXIT_ENGINE_NOT_RUNN
ING 10 /* database not running */
>#define EXIT_SERVER_NOT_FOUN
D 11 /* server not running */
>#define EXIT_BAD_ENCRYPT_KEY
12 /* missing or bad encryption key */
>#define EXIT_DB_VER_NEWER 13 /* server must be upgraded to
>run db */
>#define EXIT_FILE_INVALID_DB
14 /* file is not a database */
>#define EXIT_LOG_FILE_ERROR 15 /* log file was missing or */
> /* other log file error */
>#define EXIT_FILE_IN_USE 16 /* file in use */
>#define EXIT_FATAL_ERROR 17 /* fatal error or assertion
>occurred */
>#define EXIT_USAGE 255 /* invalid parameters on command
>line */
>/ ********************
*********/
>/* exit codes 200 to 254 are */
>/* reserved for internal use */
>/* ********************
*******/
>
>
>Breck Carter [TeamSybase] wrote:

--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com

Breck Carter [TeamSybase]

2005-07-28, 1:26 pm

On 28 Jul 2005 09:42:03 -0700, Greg Fenton
<greg. fenton_NOSPAM_@ianyw
here.com> wrote:

>The big problem is actually a MS-Windows issue (no, really).

Go ahead, slag the OS used by most of your paying customers :)

ERRORLEVEL has worked that way for 20+ years, enough time for even
*me* to get used to it.

(Young folk today are so soft... :)

Breck

--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com

Greg Fenton

2005-08-10, 3:23 am

Breck Carter [TeamSybase] wrote:
>
> ERRORLEVEL has worked that way for 20+ years, enough time for even
> *me* to get used to it.
>

Yes, but how long have people been trying to use this particular
scripting language for (proper) production server applications?

;-)

> (Young folk today are so soft... :)

I'm not as think as you old I are.

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/

Erik Anderson

2005-08-10, 8:24 pm

Irrespective of batch files and ERRORLEVEL confusion, these are the same
result codes that applications receive if they access dbtool9.dll directly
(and which my production utilities can read and report off of, although they
tend to go for the string error messages when possible). Other than the
fact that 0 should mean success, I'm not sure why this discussion is tied to
the quality of DOS scripting...

"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:42f97113$1@foru
ms-2-dub...
> Breck Carter [TeamSybase] wrote:
>
> Yes, but how long have people been trying to use this particular scripting
> language for (proper) production server applications?
>
> ;-)
>
>
>
> I'm not as think as you old I are.
>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/

Sponsored Links