Connecting to a SQL Anywhere 17 database with a VB.NET Desktop application

[baventjr]

I have an app that i have developed in VB.NET and it runs fine on my computer. My computer has the SQL 17 Database installed on it.

When I deploy the app to a client that only has an ODBC installed (used by another application to access the same database) I get the following error when trying to access the DB: System.TypeInitializationException: The type initializer for 'Sap.Data.SQLAnywhere.SAConnection' threw an exception. ---> Sap.Data.SQLAnywhere.SAException: Cannot find the language resource file (dblgen17.dll).

I have used the SQL 17 Deployment wizard and have installed it on the client but it still cannot find the "dblgen17.dll" even though I can find it on the workstation.

I must be missing something simple but any advice would be appreciated. Not sure what information you may need to answer so I will be watching for more questions.

[Vlad]

Do you have this file here? Because I have it on my PC: \\SQL Anywhere 17\\Bin64\\dblgen17.dll

[VolkerBarth]

Does the PATH variable contain the path to the SQL Anywhere 17 bin32 or bin64 subdirs?

And is your app 32-bit or 64-bit?

[baventjr]

I do have the file on the computer. C:\\Program Files\\SQL Anywhere 17\\Bin64. Yes, the path is in the System Variables in the environment.

[baventjr]

my app is a 64-bit app. Written in VB.NET.

[VolkerBarth]

I turned your comment into an answer (parallel to your new answer...) - Feel free to mark the fitting answer as "accepted answer" (see the check mark before the answer's text). And feel free to delete the second answer if it seems moot now...

[baventjr · Accepted solution]

I found my problem thanks to Volker Barth. I had "Prefer 32-bit" checked in my Compile TAB in the Project Properties. As I understand it you can't connect to a SQL 17 with a 32-bit DSNLess connection. I recompiled using X64 as the target CPU and it worked. Do I need to give credit to Volker in some way?

[VolkerBarth · Accepted solution]

As I understand it you can't connect to a SQL 17 with a 32-bit DSNLess connection.

AFAIK, you can. But your application's bitness must match that of the database client, i.e. for a 32-bit application, you would need the driver in the Bin32 subdir, the one from Bin64 won't work here.

[baventjr · Accepted solution]

Thanks, hopefully, I can test this today. I am deciding whether to install 17 drivers or changing the app to use 10 drivers.

[baventjr · Accepted solution]

I tried today to reference the SQL 10 dll in my app and could not. So I could not use the SQL 10 driver installed for access to my database. May be me but got an error when trying to reference the dblgen10.dll. I decided to deploy an SQL 11 client deployment and was able to reference in my project and with the SQL 11 deployment my app worked. Thanks for everyone's input. This is a fantastic reference for me.

[VolkerBarth · Accepted solution]

Is there a particular reason you do not use a SQL Anywhere 17 client when using a v17 server?

[baventjr · Accepted solution]

The provider of the Desktop application that we use for Order Entry and Quoting etc. provided the system initially using the SQL 10 database and ODBC. As the database was upgraded along the way the provider never updated the ODBC because it worked fine with original ODBC. It still does! I was trying to write an application using a DSNLess connection and use the SQL10 dll's. That was my goal so I didn't have to add a driver to the workstation where I was installing my app. That is the only reason.

[chris_keating · Accepted solution]

This is not the result of "you can't connect to a SQL 17 with a 32-bit DSNLess connection." It is that the 32 bit SQL Anywhere 17 ODBC driver was not correctly installed i.e., it was missing/could not find deployment DLLs such as the 32 bit language DLL (dblgen17.dll) required by the ODBC driver. I rarely make connections via a DSN i.e. all my PowerBuilder tested connections are 32 bit and are DNSLess. I have also confirmed that I can make a DSNLess connection in a .NET ODBC based connection. I have confirmed using task manager that the process is 32 bit and the loaded SQL Anywhere DLLs in that process were also 32 bit by using ListDLLs (from MS Sysinternals).