Why not just go into the stored proc and supply a field name for each field in your select into statement? I can't see how the error message can be any clearer. If you fix the bug then you won't need to improve the message any further.
Not a bad idea, but it would be quite painful doing this, statement after statement.
After every statement which could possibly fail (and which are quite complex in my case), I already check for @@error, store it in a local variable if something went wrong, and then go to an error handling section.
I just want to get the message associated to the error (which is by the way displayed in my IDE) logged into a table. Is this possible?
If you're maintaining it then that suggests it worked before you changed it - I'd suggest applying one change at a time - running it and seeing if it craps out. Quite honestly it doesn't seem to difficult to look at each select into statement and see if each field has a field name - I'd guess it would take a few minutes to do at most.
Well, that's not the only possible message. Other possible messages could come from NULL field values which shouldn't be NULL, foreign key violations and so on. I just gave that message in my first post as an example, but there could be much more than that.
I managed at this point to check for some errors upfront; and then, if something else happens, I'll live for now with the generic Sybase error + the error code.
However, I see error handling in Sybase stored procedures is pretty immature, to say it the harsh-less way I can. This has made this stored procedure's code, which was quite ugly, even uglier now.
In any case, thanks a lot for your replies and insights!
Oddly enough I rarely put error handling into my Sybase code. I know that sounds crazy to many but I just find testing the data (divide by zeros etc) before inserting it is more than enough. I think there's more bugs and limitations put into systems by the error checking than by the code - that's certainly the case for the database I'm currently having to work with. YMMV