Re: Information in SQLException

"IchBin" wrote...
> hombre wrote:

>> The following lines catch what I want:
>> catch( SQLException e ) {
>> if (e.getSQLState() == "23000" && e.getErrorCode() == 1062)
>>
>> But I am not happy with this solution because I have to
>> make code modifications when I switch to another database.
>> I wonder why there is a SQL99 or XOPEN standard that can't
>> be used in practice.

It can, if the vendors and developers follow the standards "by the letter".

Fortunately (or unfortunately, depending on the view), they don't.

SQL is to a large degree built upon Codd's relational algebra, and to a
large degree formed by the use of the "normal forms" (even though they could
be discussed much as such).

I believe the SQLState 23000 never was thought of as anything else than to
enforce a proper use of "integrity constraints", and with the "normal forms"
in mind, there actually shouldn't be more than one unique key in one single
table.

E.g. if you wan't to change the value of a primary key, AFAIK it's possible
to do so, and still keep the integrity towards child tables, through the use
of cascading foreign keys.

But all that just serves as a possible explanation to why the SQLStates are
too "broad" for explicit situations.

> Well the standard applies to the language and not vendor
> generated messages based on there DBMS implementation.
> As a DBMS vendor they can have different feature that
> they need to add their own nomenclatures of messages.
> This will never be standardized. At least it has not
> been in my 28 years of computer field. If you have
> worked with Oracle and than most any other database
> you would understand.

I would say that Oracle has improved in that respect in the last years, as
it now conforms a bit better to the standard than before. I was pretty
excited when they finally decided to implement outer joins in the standard
way...

Unfortunately, their eagerness to conform to standards has also broken a lot
of Java code. When they decided to implement TIME and TIMESTAMP according to
the SQL standard, they also decided to map DATE to java.sql.Date, instead of
java.sql.TimeStamp as they did before...

// Bjorn A


.

Relevant Pages

  • Re: Fortran 77 parser
    ... The Cray machines were built with 64-bit floating point in mind. ... routines, it was standard practice. ... I don't think COCO is supported by a single fortran vendor that I ...
    (comp.lang.fortran)
  • Re: SecurID and FreeS/WAN GW
    ... It'd be possible with any web browser and a standard IP ... non-standard hack by a vendor? ... other internet protocols --- else the web browsing block is awfully ... no more problem for this hack than for a vendor's; ...
    (Focus-Linux)
  • Re: Serious conformance BUG in lcc-win32 still present
    ... Don't you care about support for Standard C from compiler vendors? ... It might be nice if lcc-win32 had a mode in which it fully conforms to ... If a compiler vendor is not prepared to fix his product to conform on this ...
    (comp.lang.c)
  • Re: how to pass arguments to a fortran77 program from de command line?
    ... >> Because it is a vendor problem instead of a standard problem... ... It just doesn't work for the standard to require that the processor not ... that's not the error unit mentioned in the standard; ...
    (comp.lang.fortran)
  • Re: Serious conformance BUG in lcc-win32 still present
    ... Don't you care about support for Standard C from compiler vendors? ... It might be nice if lcc-win32 had a mode in which it fully conforms to ... If a compiler vendor is not prepared to fix his product to conform on this ...
    (comp.lang.c)