Jonathan Neve wrote:

> Ok. I understand better now. What you're saying is that the internal
> working has to be changed somewhat, in order to make it easier to
> manage the error messages, and that without this, people will be
> rather reticent to improve the error messages. Fair enough. Let's do
> that first then. It seems to me that whatever needs to be done in
> order to make the error message situation manageable _ought_ to get
> done, as soon as possible. This is currently a weakness that makes
> many people waste a lot of time...

I think that nobody will oppose to this enhancement, but...

> So finding the statement that failed is the first major headache.
> Then, once you've identified that, you still have to figure out what
> was wrong with it. "Arithmetic overflow or string truncation" usually
> means that you're trying to put in a certain field more data than
> will fit in. But... why not tell us which field, and what data? This
> also would save much time. Also, it would even be possible to tell us
> the PK value of the record it happened on (since sometimes the same
> statement can succeed for some records, but fail for others).

Plus an E-R diagram of the involved tables? :-)
Just kidding.

> After
> all, surely the engine should easily be able to know what it was
> trying to do when it failed...

(Lord, forgive him he doesn't know what he's saying...)
Sure. It was moving bytes without knowing where they belong.
Have a look at
http://cvs.sourceforge.net/viewcvs.py/firebird/firebird2/src/jrd/cvt.cpp?vie
w=markup
and then look for
void CVT_move(const dsc* from, dsc* to, FPTR_ERROR err)
please. Inside that function, have a look at places with code like this
(*err) (isc_arith_except, 0);
or that
conversion_error(from, err);
and you may get a clue. Do you see a trace of fields or relations here?
:-)

> Another example is that of a union. Since unions require that the
> columns from each select statement be of exactly the same type, an
> error message is issued if ever this is not so.

I think that Arno enhanced that place to be more forgiving.

> This very helpful
> error message is "Data type unknown"! This tells us practically
> nothing. It just means that some column is wrong somewhere. It would
> be nice to know which one.

Yes, it's a frustrating error. If I was MS tech support, I would tell you to
avoid unions until the next SP.

> Another example is the "Column unknown" message. This helpful message
> shows up when trying to define a trigger or a SP, for which a certain
> variable has not been defined. Couldn't we be told which one?!?
> Interestingly, if a real (table) column actually is unknown, a proper
> error message is shown. This problem only occurs in the case of
> SP/trigger variables.

I was able to extract the column name and tell you it in FB1 because the
engine made it available. In the case of a SP, I don't remember the case. An
example in fb-devel is welcome, since the simplest test I did left me in
doubt:

SQL> create database 'kitten.fdb';
SQL> set terminator &;
SQL> create procedure p as declare x int; begin if (h > x) then exit; end&
Statement failed, SQLCODE = -206
Dynamic SQL Error
-SQL error code = -206
-Column unknown
-H
-At line 1, column 52.

Again, I have to ask: when you express your concerns, what's the server
version you are using as an example?

C.