Subject | RE: [Firebird-Architect] Re: SQLSTATE and Firebird |
---|---|
Author | Tom Cole |
Post date | 2006-05-04T12:58:32Z |
This works for me. I don't think a 1:1 mapping is needed, just something which allows an algorithmic determination.
-----Original Message-----
From: Firebird-Architect@yahoogroups.com [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Dmitry Yemanov
Sent: Thursday, May 04, 2006 8:45 AM
To: firebird-architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Re: SQLSTATE and Firebird
Tom,
The primary GDS code isc_arith_except should remain intact. But we should add secondary GDS codes to separate between exception types, to carry some context info, etc. For example:
{ isc_arg_gds, isc_arith_except,
isc_arg_gds, isc_string_trunc,
isc_arg_end }
So the SQLSTATE code could parse the entire status vector to find all GDS codes that are necessary to make a decision about some definite SQLSTATE.
Yeah, it means that a simple GDSCODE->SQLSTATE mapping won't work, but it was just a simplest solution, not the only possible one.
Dmitry
-----Original Message-----
From: Firebird-Architect@yahoogroups.com [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Dmitry Yemanov
Sent: Thursday, May 04, 2006 8:45 AM
To: firebird-architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Re: SQLSTATE and Firebird
Tom,
The primary GDS code isc_arith_except should remain intact. But we should add secondary GDS codes to separate between exception types, to carry some context info, etc. For example:
{ isc_arg_gds, isc_arith_except,
isc_arg_gds, isc_string_trunc,
isc_arg_end }
So the SQLSTATE code could parse the entire status vector to find all GDS codes that are necessary to make a decision about some definite SQLSTATE.
Yeah, it means that a simple GDSCODE->SQLSTATE mapping won't work, but it was just a simplest solution, not the only possible one.
Dmitry