The connection string for an ADO object is the programmatic way of describing what you are doing in management studio. You're not going to find the connection string explicitly stated in SQL Server Management studio.
I don't know the specifics of your environment so I'm not sure which string precisely to use. However, if you go to https://www.connectionstrings.com/sql-server/ there are a variety of examples there.
This is the one I've use most often in my environments. Replace the bold items with the specifics for your environment.:
Provider=SQLOLEDB.1;Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;
SmartBear support desk helped me out with it as well, with these steps on how to get the Connection String from MS Visual Studio:
You can try connecting to your database from Visual Studio:
Hi,
Another possible approach is to use .udl file and steps from here: https://community.smartbear.com/t5/TestComplete-Functional-Web/Can-anyone-help-me-how-to-access-Mongo-database/m-p/86460#M20415
As for the dbTable checkpoint...
If you open the file that corresponds to some given dbTable checkpoint with some text editor, you will notice that it contains (static) snapshot of the database data returned by the SQL entered when creating checkpoint. When called from the test, checkpoint gets new data from the database using the stored SQL expression and compares the obtained result with the stored one.
The above algorithm implements the approach that is a recommended one for the unit testing, when a new clean database is created before test execution and then test is executed using predefined static set of data. dbTable checkpoint works perfectly fine for this approach and scenario.
On the contrary, functional, end-to-end testing, that most of us is doing with TestComplete, does not assume re-creation of the clean environment before every test and static test data are not recommended as well. For this type of testing, dbTable checkpoint is nor the best tool, indeed.
Now that you have it connected, and as you start to play around with what you can do with this connection, I suspect you'll find it's pretty powerful.
I do all sort of SQL related stuff in my tests. Verify counts, verify full records/single fields, record addition, record removal, allows for use of a timestamp so you don't have to reset the DB constantly (although it also allows you to create and restore backup DB's if you wish), etc etc. It's all built into my Framework as a script extension now and is very easy for the test guys to use. And they can fire it any valid SQL query they like. They just store the query as a small file, reference the file location (usually in the same folder as the driver sheet, but doesn't have to be) in the call on the driver sheet, and it will run that query and perform the appropriate check on the resulting RecordSet object.
(One thing I will add .... I don't like RecordSet objects. They're horrible klunky things to work with IMHO!)
