Hi Ann and all,

Ann W. Harrison wrote:

>The first problem here is that once upon a time there was a way to
>manage error messages and add them easily. Now the tools are
>obsolete so adding an error message is hard.
>
>

I see.

>A second problem is that when Borland integrated the various
>utilities into the services API and merged their error returns,
>the numbering of message exceeded the ability of, well, me, for
>example, to manage mentally. So I need the tools.
>
>

Ok.

>A third problem is that the easy way to add an error message - use
>isc_$random and a text string - is a horrible violation of any standard
>of internationalization. We've got this message facility designed for
>translation - hard coding messages is a serious step backward.
>
>

Absolutely.

>If we make it easier to add messages, the resistance to fixing ambiguous
>messages will go done.
>

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...

>For now, it's just so much easier to use an
>imprecise but reasonably appropriate message that we can't fix the problem.
>
>

Well, the messages are indeed sometimes reasonably appropriate, but not
always. This is especially true for SPs and triggers. If you have a long
and complicated SP, which you call from your application, and you get a
message such as "Arithmetic overflow or string truncation", where do you
look? I had a case like this not long ago. Since there is no indication
as to which part of the SP failed, you have to read through the whole
thing, trying to figure out what could be failing. Of course, you can
comment things out, but even this isn't very reliable, because
statements are often interrelated, such that commenting out one block of
code might stop a subsequent block of code from failing...

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). After all, surely the
engine should easily be able to know what it was trying to do when it
failed...

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. 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. (Also, as a side note, I think in cases when it's possible,
it would also be nice if there was some implicit casting. For example,
if there are two varchars of different sizes, why not take the larger of
the two, and implicitly cast the other one to the right type. This would
get rid of a lot of the hassle of using unions. The same is true for
numerics. However, there obviously shouldn't be any implicit casting
between varchars and numerics and dates, etc.)

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.

So while it's true that with a bit of experience, one can get used to
the imprecision of the error messages without wasting as much time as a
beginner, I still think there's plenty of room for improvement in this
area. We all could be spared a lot of time and effort if it were but for
more precise error messages.

Regards,
Jonathan Neve.