Subject Proposal to add SQLState to Vulcan
Author Bill Oliver
Hello all!

I would like to propose a new API, isc_sqlstate() for Vulcan that would
return the SQLSTATE information. I have this mostly working within a
playpen, and now is a good time for me to share my design proposal.

I've uploaded the document to uploaded files section of the firebird
architect group. This covers the current SAS implementation, which I
want to replace (you can skip that part), along with the new code. I've
highlighted the parts I wasn't sure about. I also uploaded a spreadsheet
and SQL file which shows my proposed datafill - that's the hard part.

This feature will require changes to the message database. Obviously, we
have to new SQLSTATE information. But there are also a couple of places
where today's error message is ambiguous, and needs to be un-ambiguated

Here's one. We have SQLSTATE 22001, "String data, right-truncated" and
SQLSTATE 22012, "Division by zero". But, we have one Firebird message
that is printed for both of these case:

SQL> recreate table test (c char(5 ) ) ;
SQL> insert into test (c) values ('text123') ;
Statement failed, SQLCODE = -802
arithmetic exception, numeric overflow, or string truncation

SQL> select (1/0) from rdb$database ;

Statement failed, SQLCODE = -802
arithmetic exception, numeric overflow, or string truncation

Here's a case where we don't generate a specific error, but should. We
should map error below to SQLSTATE 42S21, "Column already exists."

SQL> create table test (i integer) ;
SQL> alter table test add i integer ;
Statement failed, SQLCODE = -607
unsuccessful metadata update
-attempt to store duplicate value (visible to active transactions) in
unique index "RDB$INDEX_15"

Those were the only ones I've seen so far - there are likely more.

I am comfortable integrating what I have (after review) into SF Vulcan.
But, I would like some guidance on the message database changes I

I think it would be better to make these database changes also to FB2
head. I don't like adding new messages to Vulcan message database only,
since these will likely be forgotten / overwritten when the merge occurs
and the GDSCODEs get out of sync. It is better, I think, to keep FB2 as
the master version of the message database. I've tried to do this in the
past by communicating any proposed message file changes to the team. A
few times Claudio has then helped me by making the necessary change in

If the message database file changse are pushed to FB2, the code changes
could wait until the FB3 timeframe.

I look forward to your response!