On the ADO error thing I tend to have a local stored procedure variable that I use to record errors that occur within the stored procedure.

Obviously I try and test and trap the situation that may fail because letting it occur may result in a stopped procedure.

I'll either have this as a straight "count the errors" type thing or as a bit map value so I can say "this error happened" AND "this error happened".

I will either have this as the @@RETURN_VALUE parameter (the one passed back to VB by the SQL RETURN statement) or as a.n.other SQL OUTPUT variable.

If there is some complicated logic within the stored procedures that would cause problems in flow then I try and break out that functionality into separate procedures.

I've done some experimenting with the severity levels to see what fires off the VB error trapping routines. I don't have my results to hand but I think errors with severity 11 and above raise errors in the VB program that can be caught with the ON ERROR GOTO statement. I seem to remember that you get a generic ODBC error number + whatever message is actually returned from SQL.