New error codes.

    The documentation states that "applications written for InterBase V3.3 or V4.0 that check for specific values of SQLCODE should be reviewed against changes in the error code list. Available in embedded SQL and stored procedures and through the API, there are two kind of error codes: SQLCODE, recommended for easy porting to other databases (where several errors can have the same code) and GDSCODE, a unique number for each error, associated with a symbolic name that provides extended information and it's returned in the status array (error status vector). The following error codes are new in InterBase 5.0:

isc_udf_exception (335544740L). Windows NT & Windows 95 only. In IB4, exceptions generated in UDFs or BLOB filters went mostly undetected. In IB5, the server detects them, prints a message and terminates.

isc_lost_db_connection (335544741L). Windows NT & Windows 95 only. This error is supposed to be meaningful only to local clients and it appears when the server loses the connection with the db. This will be probably due to a server crash.

isc_no_write_user_priv (335544742L). In IB4, clients were allowed to write directly to system table RDB$USER_PRIVILEGES that was new in v4 to manage SQL permissions instead of the old RDB$SECURITY_CLASSES table. Now, all operations are expected to happen through DDL commands GRANT and REVOKE.

isc_token_too_long (335544743L). Any single token in a DSQL statement may not exceed 255 characters. I'm not sure how a token could be so long since identifiers are limited to 31 characters, but this is a good measure that prevents buffer overflows.

isc_max_att_exceeded (335544744L). Since IB5 implements the attachment governor, it denies a new connection when there're already N attachments, with N being four times the value of the authorized USERS in the license file.

isc_login_same_as_role_name (335544745L). Since IB5 implemented SQL roles in system table RDB$ROLES in each database, a user (login) name defined in isc4.gdb cannot be the same than a role defined in such system table, otherwise the login is denied. This has been used as a basic measure to prevent SYSDBA to log in a specific database, because Borland protected RDB$USER_PRIVILEGES from direct manipulation (see error message isc_no_write_user_priv above) but same as with IB4 with that table, being RDB$ROLES new in IB5, it wasn't protected from direct manipulation: the CREATE ROLE statement won't accept SYSDBA as a name, but a direct insertion over RDB$ROLES will allow anything.

This page was last updated on 2001-02-04 02:13:08