Well, result set was just an example. I don't know, off hand, the specifics of every SQL command that can be executed via ADO. But the principle that I mentioned is still the same: exceptions raised in the SQL will not re-raise as exceptions in your DelphiScript. So, yes, on the SQL server side, it would raise as an exception if your SQL is coded to do so. But the ADO COmmand object "handles" that exception so that it is not reraised. In order for you to determine success/failure of the SQL you'll need to either examine whatever results you DO get back (could be numeric error code, status code, etc) OR, run a subsquent query to determine the state of the database after the command to see if it completed successfully.
I could be wrong in this, but that's been my experience.
Hi, Robert.
I understand that you said.
But, why it works different when my syntax is incorrect? In this case the exception is raised.
Because in that case, it's not the SQL server that's raising the exception but your utilization of the ADO objects.
Hi, Robert.
What alternative would you use to solve this problem?
Do we only have "ADO" to send instructions to the database with TestComplete?
Making a subsequent query does not seem to be a good practice, because each case will require a specific subsequent query, and I will not have how to predict everything.
Does TestComplete accept the use of other connection drivers like DBExpress for example?
Thank You.
I'm not sure another database driver will work any differently. I'm not an expert but I'm pretty sure that however you connect to your SQL database, whatever object/driver that you are using "masks" the exceptions that SQL Server returns. Whether it's ADO or some other driver type, you are limited by what those objects actually return... there usually is no "re-raising" of exceptions in your query back to the calling application.
Someone else may have a different solution.
As to using those other drivers... so long as you can instantiate them with something like Sys.OleObject or something like that, then yes, you can use them. They won't have the built-in wrappers like TestComplete does for ADO, but you should be able to use them on a lower level.
