Handling Errors

mIRC SQLite

Handling Errors
mIRC SQLite has a simple and effective way to do error handling. Unlike in many APIs, there is no function to query the database for the last error. Instead every mSQLite function sets two special variables that can be examined to determine the cause of an error:
%sqlite_errno    Holds the error code of the latest operation.
%sqlite_errstr   Holds the error string of the latest operation.
There is also one special function that can be used to get a string representation of an error code, $sqlite_error_string.
The returned string isn't necessarily the same as the %sqlite_errstr. Sometimes %sqlite_errstr contains a specific error message when an error is returned. For example, whenever %sqlite_errno is set to $SQLITE_INVALIDARG, %sqlite_errstr will contain a specific error message of which argument is invalid and why. Similiarly when opening a database or executing a query fails, %sqlite_errstr will contain the specific error message, while %sqlite_errno contains the type of the error.

There are two ways to determine if there was an error in a mSQLite command or identifier. The first way is to check the return value of the identifier, which is always $null in case of an error. In case $null is returned, you can then use the %sqlite_errno and %sqlite_errstr to determine the exact cause of the error. The other way to check for an error is to examine the variables after the call to the function.
NOTE. In case you call mSQLite functions as commands (eg. /sqlite_* instead of $sqlite_*), you can also use the $result identifier of mIRC to see what was returned.
Error codes
Here is the list of error codes that %sqlite_errno can consists:
Identfier             Description                              Code
$SQLITE_OK            not an error                                0
$SQLITE_ERROR         SQL logic error or missing database         1
$SQLITE_INTERNAL      an internal logic error in SQLite           2
$SQLITE_PERM          access permission denied                    3
$SQLITE_ABORT         callback requested query abort              4
$SQLITE_BUSY          database is locked                          5
$SQLITE_LOCKED        database table is locked                    6
$SQLITE_NOMEM         out of memory                               7
$SQLITE_READONLY      attempt to write a readonly database        8
$SQLITE_INTERRUPT     interrupted                                 9
$SQLITE_IOERR         disk I/O error                             10
$SQLITE_CORRUPT       database disk image is malformed           11
$SQLITE_FULL          database or disk is full                   13
$SQLITE_CANTOPEN      unable to open database file               14
$SQLITE_PROTOCOL      database locking protocol failure          15
$SQLITE_SCHEMA        database schema has changed                17
$SQLITE_TOOBIG        too much data for a row                    18
$SQLITE_CONSTRAINT    constraint failed                          19
$SQLITE_MISMATCH      datatype mismatch                          20
$SQLITE_MISUSE        library routine called out of sequence     21
$SQLITE_NOLFS         kernel lacks large file support            22
$SQLITE_AUTH          authorization denied                       23
$SQLITE_FORMAT        auxiliary database format error            24
$SQLITE_RANGE         bind or column index out of range          25
$SQLITE_NOTADB        file is encrypted or is not a database     26
$SQLITE_INVALIDARG    invalid argument                          200
$SQLITE_NOMOREROWS    no more rows available                    201
$SQLITE_NOTMEMORYDB   not a memory database                     202
You should always use the identifiers instead of code values when comparing error codes. This is because the error codes are a possible subject to change in future. By using the identifier you'll ensure compatibility with future versions.