This Q&A was previously posted on the Stack Exchange Network of websites.
This content is licensed under the Creative Commmons Attribution-Sharealike (CC BY-SA) license. As the author of these answers, this archive serves as a canonical location for permalinks, which will outlive Stack Overflow. See all my answers by looking at the Stack Exchange post category.
UFT to SQL Server conecction which is located at different domain
Question
I need to connect to a SQL Server through UFT (Unified Functional Testing) but the problem is SQL Server is present at different domain whereas QTP (HP QuickTest Professional) is present in a different domain.
I am able to connect to SQL Server manually from my domain using
runas /netonly /user:mydomain\TestUser
"C:\Program Files\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe
Where mydomain is the domain in which the SQL Server is present. This is working fine when I connect it manually, but it failed to establish a connection when I tried to connect it through QTP.
Connection string that I’m using:
provider=sqloledb.1;server=10.130.15.11,1421;uid=testuser;password=mypassword"
The password in the connection string is different from the password that I provide after executing above runas command. I also tried with passing both the domains in UID in connection string in QTP but still not able to connect.
asked 2016-03-29 by alphaTester
Answer
The uid & password attributes are used for SQL Server Authentication. You cannot use those connection string values with Windows Authentication. I suspect you are getting login failures with error 18456, state of either 2 or 6. The state portion of the failure message will give you the detailed reason for failure. This post by Aaron Bertand gives a detailed rundown of most/all possible failure reasons.
If you want to use Windows Authentication to connect to SQL Server from a different domain, you would need to have a trust established between the two domains. With the trust established, you would replace the uid & password attributes with Trusted_Connection=True;
If your second domain is not trusted, and you cannot establish a trust, then you would need to use SQL Server Authentication instead. You would need to create the SQL Server login, and then your existing connection string format would work.
answered 2016-03-29 by Andy Mallon