>>Thank you, Thomas. I already capture the content of the error() array. I was looking to see if there is anything "extra" I can get to the error log file.
>
>Route your SQL through one class so there you can have the error catching code in one place. If SQLExec() returns 0 or less, aError() and then log the contents of the array. Mind you, you may get multiple rows. Ditto for COM errors, where On Error and Try-catch will just say it's an OLE error or some such, aError() may give you additional info.
>
>The trouble with using aStackinfo() with try-catch is that it will have the catch command as the place where it happened, which isn't quite helpful, specially if the error occurred several calls deep inside the try-catch block - you won't know where. So better start making smaller catch blocks at deeper levels and also log all relevant properties of the exception object - the actual routine and lineno where the error happened is in there, which may help you narrow down the location.
First, thank you for your input. Secondly I don't use SQL through; my application is using CA. And I do use SQLExec(). But the SQL Select/Insert/Update do not give me any problems since I learned how to catch them right at the point where they are executed. When I look at some customers' error log I see mostly the error caused by a problem instantiating objects. And so far, I have not learned how to catch those.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham