SQL server database connection issue

[JC51]

Hello everyone,

I'm currently experiencing an issue when deploying software that uses a SQL database. Everything works correctly on my development PC, however on the PC where I want to install the software, when launching the application, I cannot connect to the SQL database. The SQL database runs on one of the company's servers.

• My Development PC: Windows 10 64-bit PC, Labview 2024 Q1 32-bit + Database Connectivity Toolkit, SQL Server 2014
• Target PC: Windows 10 64-bit PC, it doesn't have Labview or SQL Server

For deployment, I created an installer that only includes the Labview runtime to run the exe on the target PC

Regarding the SQL database connection, I tested two methods:

• The complete connection string in the format "Provider=sqloledb;Data Source=SQL-WS2022;Initial Catalog="DB_Name";User Id="Username";Password="User_Password" which I connect directly to the "Database connection" VI
• Using Windows ODBC32 Data Source (32-bit) (Windows\system32\odbc32.exe) => Creating a new database then entering the database name in Labview + username and password. With this method, in ODBC32 I complete the connection and it indicates that the connection with the server was successful EXCEPT that with Labview, I get an error message.

Both methods work on my Development PC but not on the Target PC. Do I need to install an add-on on the target PC? If so, which one? I don't really understand why it doesn't work with method number 2 (with ODBC32 Data source) because it indicates at the end that it can connect to the database.

Here's the error message=> ADO Error: 0x800A0E7A Exception occurred in ADODB. Connection: Provider cannot be found. It may not be properly installed.

If someone has already encountered this problem and knows how to solve it.

Thank you in advance. Have a good day.

[LVNinja]

Hi I created executables that access SQL server databases before. Ensure that you  included the UDL file on the "connection Information" input on the "DB Tools Open Connect" function.

[aputman · Accepted solution]

If you go the ODBC route with 64bit OS and 32bit LabVIEW, you need to use the app in Windows\SysWOW64\odbcad32.exe.  It isn't clear at all but the sysWOW64 folder contains 32-bit system apps.  I know the ODBC app that you are using says 32bit in the titlebar, it's named odbc32.exe and it's located in the System32 folder but it's not 32bit. Go figure. 

[rolfk]

---

@aputman wrote:

If you go the ODBC route with 64bit OS and 32bit LabVIEW, you need to use the app in Windows\SysWOW64\odbcad32.exe.  It isn't clear at all but the sysWOW64 folder contains 32-bit system apps.  I know the ODBC app that you are using says 32bit in the titlebar, it's named odbc32.exe and it's located in the System32 folder but it's not 32bit. Go figure. 

---

This is the solution for your approach 2). For some reason when Microsoft ported Windows to 64-bit they decided it was a smart move to keep the 64-bit components to remain in system32, so that a developer porting his 32-bit application to 64-bit won't need to have to change fixed path names in his application and installers. And to fix that for existing 32-bit application they added so called redirection where Windows automatically redirects system32 to SysWOW64 when called from a 32-bit application, except when you add additional flags to some APIs, or change some global process wide variable to skip automatic redirection and, and, and.

1) likely doesn't work since the (32-bit version) of the driver you specify, is not installed on your target system. MS SQL drivers are legions and come installed in many flavors and various products. Each is doing more or less the same thing through various different interfaces (ODBC, OLE DAO, .Net DB and several variants of these). MS Office 13 comes with a different set than your Office 365, installation of Excel alone can add additional ones, MS SQL Server comes with its own variant depending on version, and so on. Each is installed under a different name and if the driver name that you specify in the Connection string is not exactly like what is installed on your computer, the database management layer won't be able to find it, just as your error message says.