0

The most subtle errors will often hide inside an ADODB.Command object. In VB and ASP, by default, if you don't explicitly check the .Errors property, you nothing will tell you that something has gone wrong with the database.

Having just discovered this, and having a large codebase with hundreds of ADODB calls: Is there any single setting that can cause these Command objects to throw a server error? Or do I really have to wrap or append every ADODB operation in a IF cmd.Errors ... check?

feetwet
  • 3,248
  • 7
  • 46
  • 84
  • @AnsgarWiechers sorry disagree never needed to check it yet, most of the time *(in a SQL Server)* environment at least it just contains warnings not errors. If a query is going to fundamentally fail it will throw a provider error which triggers a `HTTP 500 Internal Server` Error. Unless you are looking for a very specific condition it's not much use. – user692942 Aug 28 '16 at 19:56
  • @Lankymart - Basically, if there's something in there, I want the server to be very loud about it. [In this example](http://stackoverflow.com/q/39185679/2662901) it did not trigger a 500, and I couldn't figure out why the query wasn't working until I dug in and discovered this (at least in that case) silent property. – feetwet Aug 28 '16 at 20:25
  • That's simple always declare all parameters regardless of whether they are optional or not, that's lesson one of using `ADODB.Command` parameters. If a value is optional or you want to use the default, don't set the parameter `Value`. This way you will never have that problem. – user692942 Aug 28 '16 at 21:48
  • 2
    @feetwet if it didn't trigger an error, your problem is not ADO but an `On Error Resume Next` somewhere in your code. – Kul-Tigin Aug 28 '16 at 23:37

0 Answers0