"Jonathan Neve" <jonathan@...> wrote:

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

If you want to have a clear indication about the problematic statement, BLR
should be extended first to incapsulate line numbers produced by DSQL. This
is not the case now - runtime errors don't have a source context and cannot
point you to anywhere.


Dmitry