On 28-6-2014 11:29, Dmitry Yemanov wrote:
Usually, the status vector has one error or a number of dependent errors
(first one is primary and others are qualifying the primary one).
Sometimes it contains errors that may look independent, but in fact
they're dependent (one error may cause
I am working on replacing the protocol implementation, and now I am
running into a 'problem' with parsing the status vector (or actually
with the result of that parse).
Currently I treat each isc_arg_gds and isc_arg_warning as a separate
exception that is chained to the previous exception, but
You shouldn't have to care. The status vector is a well defined, self
describing data structure. A transmission protocol should pass it, not
interpret it. If you have to get involved in the semantics, you're either
doing something wrong (or somebody screwed up the architecture).
That said, the
On 28-6-2014 11:14, James Starkey wrote:
You shouldn't have to care. The status vector is a well defined, self
describing data structure. A transmission protocol should pass it, not
interpret it. If you have to get involved in the semantics, you're
either doing something wrong (or somebody
28.06.2014 12:38, Mark Rotteveel wrote:
I am working on replacing the protocol implementation, and now I am
running into a 'problem' with parsing the status vector (or actually
with the result of that parse).
Currently I treat each isc_arg_gds and isc_arg_warning as a separate
exception
28.06.2014 11:14, James Starkey wrote:
That said, the philosophy is that the frst code is primary -- something an
application
programmer can make part of his application logic.
What logic can be built on isc_dsql_error - something happened in DSQL
which is used
to be a primary code for
DSQL was originally a client side facility that used the public DB2 SQL API
for the lack of any other standard. The DB2 API returned only SQL codes.
Borland turned DSQL from a client facillity to a server facility. In the
process, they integrated the DB2-like API into the larger Interbase API,
