Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4429C31F.5040102@apache.org>
Date: Tue, 28 Mar 2006 15:13:35 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Compatibility guarantees for SQL states and messages
References: <44288508.6060700@sun.com> <442995A2.7020705@sbcglobal.net>
 <4429BFBC.7000406@sun.com>
In-Reply-To: <4429BFBC.7000406@sun.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

David W. Van Couvering wrote:

> Thanks, Kathey.  What if I find an existing SQLState in the embedded
> code that uses a Derby-specific SQL State but which I think really
> should be a standard SQL state?
> 
> For example, I think 42X89 ("Types ''{0}'' and ''{1}'' are not type
> compatible. Neither type is assignable to the other type.") really is a
> case of the standard SQL State 22005 - "error in assignment"

Ideally since these SQLState's are from the SQL Standard there should no
"I think" about changing any. It should be driven from the
specification, e.g. text that says "... then an exception condition is
raised: data exception � error in assignment."

In this specific case '22' is a data exception, some exception raised
due to the value of the data. '42' is a compile time error, in this case
raised because the types are not assignable to each other, not because
the specific data values are not assignable to each other.

We just need to be careful when selecting errors to ensure we are using
SQL states correctly.

Dan.