By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,236 Members | 1,423 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,236 IT Pros & Developers. It's quick & easy.

significance of SQL state?

P: n/a
Someone explain the significance of SQL state?

Oct 13 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
compguy wrote:
Someone explain the significance of SQL state?
From a standard's perspective, it's supposed to be _the_ mechanism to
communicate error states from the DBMS to the application.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Oct 13 '06 #2

P: n/a

Knut Stolze wrote:
compguy wrote:
Someone explain the significance of SQL state?

From a standard's perspective, it's supposed to be _the_ mechanism to
communicate error states from the DBMS to the application.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Am I right in thinking that different suppliers use consistently
different SQLCODEs for the same errors and that intellectual property
rights laws probably ensured that they had to do so. However, I
believe that they all use +100 for no data. SQLSTATE provides more
detail and also provides some logical grouping of error categories.

Robert

Oct 13 '06 #3

P: n/a
Robert wrote:
Am I right in thinking that different suppliers use consistently
different SQLCODEs for the same errors and that intellectual property
rights laws probably ensured that they had to do so. However, I
believe that they all use +100 for no data. SQLSTATE provides more
detail and also provides some logical grouping of error categories.

Robert
There are no intellectual property issues. The SQLSTATE was
specifically added to the SQLCODE to allow everyone to use a standard
set of error messages. However, like many other standards, not all
vendors have adhered to them.

It probably can be used with some sucess to port applications accross
various IBM relational products.

Oct 13 '06 #4

P: n/a
Mark A wrote:
Robert wrote:
>Am I right in thinking that different suppliers use consistently
different SQLCODEs for the same errors and that intellectual property
rights laws probably ensured that they had to do so. However, I
believe that they all use +100 for no data. SQLSTATE provides more
detail and also provides some logical grouping of error categories.

Robert

There are no intellectual property issues. The SQLSTATE was
specifically added to the SQLCODE to allow everyone to use a standard
set of error messages. However, like many other standards, not all
vendors have adhered to them.

It probably can be used with some sucess to port applications accross
various IBM relational products.
Across the DB2 family both SQLCODE and SQLSTATE are quite portable.
(Quite as in there are exception, but we maintain a central and shared
catalog of our error codes).

Teh story on SQLCODEs is that in the early days of System R, some
upstart company called Oracle asked for System R's SQLCODEs.
IBM, at that time not particularly standards oriented and quite possibly
a tad ;-) arrogant declined. Now we got the mess...

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/
Oct 13 '06 #5

P: n/a
>Someone explain the significance of SQL state? <<

This is a part of Standard SQL. SQLSTATE is an alphanumeric string
that returns error codes. The first two characters are a category and
the rest of the string is a detailed breakdown. There is some room for
proprietary additions to the scheme.

It replaced SQLCODE, which was a numeric code for the same purpose, but
not as detailed.

Oct 14 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.