At 10:01 PM 4/05/2006, you wrote:

>I'm not qualified to have an opinion about what constitutes a
>critical compatibility issue between Firebird versions, but I would
>think there are implications to changing the general case for a
>documented return code, aren't there? Or do FB's clients/consumers
>tend not to make specific decisions about errors based on _specific_
>return codes?

I don't. The SQLCode is useless. But the ISC error codes are
grouped beneath the SQLCodes (in a fairly arbitrary way) and they (a)
come back in the status vector and (b) are accompanied by the
*useful* message from firebird.msg.

>It seems like there are two choices:
>
>1. Changing the return code messaging, by introducing new
>return codes to augment the isc_arith_except ( which could be
>reserved for overflow and underflow conditions in their many forms)
>like the following:
>
> isc_arith_zerodiv
> isc_string_trunc
>
>
>2. Alternatively, since we already return a vector of
>additional data, we could simply add the above items to the vector
>as ancillary data. This would presumably not change the "primary
>return code" for the entry points, but would allow someone
>post-processing the vector to get additional context to choose a
>proper SQLSTATE. If this route was chosen, I'd prefer to add an
>explicit additional state for underflow/overflow like
>isc_arith_overflow or something similar.

I've been sort of following this...is there any reason why we can't
map the userland SQLSTATEs to the isc codes? As it stands, we have a
9-digit isc code of which only the final four (or is it five) digits
are meaningful; to map to an 8-byte alphanumeric code, of which the
majority of possible permutations are not reserved for (supposedly)
standard use. The first 2 bytes are supposed to represent the class
(could be mapped to Fb's SQLCodes?) with 6 bytes for specifics (or
something similar, according to Melton's book).

As long as there's no thought of abolishing the isc codes (and
corresponding gdscodes for PSQL exceptions). That would not wash at all.

Helen