Forum Discussion
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.
- tristaanogre6 years agoEsteemed Contributor
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.
- jhonathanramos6 years agoOccasional Contributor
Hi! :smileyhappy:
I'm also not an expert, but in more common development tools we often have this database return, about when we have a "integrity constraint," for example. Not even in this case do I get a response using "ADO".
For this reason I am believing that using another driver to connect with the database could raise these exceptions. :smileyindifferent:
Maybe there is another way in TestComplete itself that I do not know, so here I am trying to understand how it works.
TestComplete is a great tool for developing scripts, I can not believe I can not do this. :smileysad:
- tristaanogre6 years agoEsteemed Contributor
Because TestComplete is for developing scripts that execute within the specific execution engine of TestComplete. So, there is a scoping that is happening, I believe, where that engine does not have access to the exceptions raised by the SQL database. You will need to create something taht does that can be called within the TestComplete engine...
Related Content
Recent Discussions
- 14 hours agodhundley