At 03:12 PM 7/02/2004 +1100, you wrote:

>It seems to me that Arithmetic Overflow and String Truncation exceptions are
>quite different in nature but unfortunately they fire the same exception.

Actually I agree that this age-old message is plain silly. The exceptions
are similar - both are overflows! I've never been able to work out why the
original author called a string overflow a string truncation - since
nothing gets truncated!

>Makes it hard to find what the exception is referring to.
>Is there any talk of making these two things separate exceptions?

I haven't heard any talk of making them separate exceptions, since both are
of the same generic type of exception. Changing the message would be
really easy.

>Can we not
>just swallow string truncation exceptions anyway when desired?

Then wouldn't it be rather pointless to define a column of a specific
size? After all, the purpose of data-typing is to ensure that the stored
data fits the specification.

>While I develop import routines, it's maddening sometimes to track down
>what part of the srupid access data is springing this exception on me.

Yeah, I'm a real cynic with data import routines nowadays. CAST()
everywhere. That gives you the means to truncate strings and massage
numbers *before* they get thrown at the columns.

Claudio and others have discussed several times providing some kind of
capability to identify the column that the overflow applies to and pass it
up the tube with the exception ID. AFAIU, currently, the structure that
carries the exception data doesn't have provision to do it. It would be
very convenient, though. You can, of course, do it in a stored procedure
now with 1.5 - pass a run-time string attached to an exception, like 'Value
nnnn is too long for column xxx'.

/hb

>