I have a an asp.net app that uses a SYSTEM DSN, and it works fine on local machine. After deploying to a 64 Bit server I am unable to connect to the DB using the dsn.
Here is what I did, I created the 32 bit system DSN on the server and it tested connection correctly ( created it under %WINDIR%\SysWOW64\odbcad32.exe . The 64 bit DSN entry is empty (at %WINDIR%\System32\odbcad32.exe).
Now When I run the app it seems like it is trying to find the system dsn entry in the 64 bit ODBC driver instead of the 32 bit.
Is there a setting on the Odbc connection that will force it to look at 32 bit DSN entry ?Is there a server config that I need to change .I havealready set the app pool on iis to enable 32 bit apps , but it didnt help ..I have been banging my head on this for hrs , any help is appreciated..Thanks
Some how you've got things mixed up. 32 bit apps look in one place for DSNs and 64 bit apps look in another place. You cannot mix 32 bit apps with 64 bit ODBC drivers (or vice versa) so it does not make sense for the setting you enquire about.
Related
Want to connect to ACCDB file as an ODBC (rather than OleDb) data source in ASP.NET but struggling with the connection string. As I plan to deploy the web app from Visual Studio 2019 to Azure, I need something that can make the journey.
Here's what I tried from connectionstrings.com (I discovered not all of those strings are up to date or necessarily convenient for insertion to web.config):
Driver={Microsoft Access Driver (*.mdb, *.accdb)};Dbq=C:\mydatabase.accdb;Uid=Admin;Pwd=;
This returns keyword not supported: driver from IIS Express where I'm doing development.
Hum, that looks ok:
I would suggest this:
Driver={Microsoft Access Driver (*.mdb, *.accdb)};
dbq=C:\test\test44.accdb;driverid=25;fil=MS Access;
maxbuffersize=2048;maxscanrows=8;pagetimeout=5;safetransactions=0;
threads=3;uid=admin;usercommitsync=Yes
the above is what the connection builder in Visual Studio spits out.
and you have Dbq - carefull - caps I believe matters - so try dbq.
Next up:
HUGE HUGE elephant in the room.
are you using a x32 bit driver, or the x64 bit one? YOU MUST match your project bit size (code compile) settings to the driver (YOU MUST!!!).
So this:
you MUST set and force your project to run as x32 bits. (or perhaps install the x64 bit version of Access drivers. AND BE careful. If you are running the x64 bit versions of the drivers, and use Test connection with Visual Studio? It will always fail since VS runs as a x32 bit applcation. you MUST RUN the applcation to test the connection - NOT use test connection with VS connection builders (you might not be using them, but if you are, just trying to save you a day of work wasted).
so, create a x32 config project. And thus this now:
And I assume your sample connection using c: or "root" of the drive is a JUST a example, since most windows now don't allow a file to be used directly from c: root location.
I have a Sage 100 ERP install running on a server and I would like to make a database query through Excel to pull data from the database. I'm running a 64 bit operating system and when I look in the 32 bit ODBC Data Source Administarator, the only DSNs that appear are:
[
When I look at the drivers tab, the MAS 90 4.0 ODBC driver is present.
Should SOTAMAS90 be created automatically as a DSN or should I try to create it manually?
Next tab over. It's a System DSN.
Let us know if you need more help.
Aaron
I'm using sqlAnywhere 5.0 to create ODBC with third parties software house
I'm running it on windows XP without any error / problem
but 8/4/2014 Microsoft announce to stop service for windows XP
then our company migrate all client PC to windows 7x64
Now the application always hang and closed itself
I would like you suggest what can I do, I'm trying to test under SQL Anywhere 12.0 but I cannot config ODBC to open application
I also attached a picture (ODBC from rtdsh50.exe)
Start command is "C:\Starlims8\SqlAny50\Win32\rtdsk50.exe -d -c4000"
Please advise, Thank you in advance.
According to the image, you are using the version 5 runtime engine. This software is almost 20 years old... I am not surprised you are having trouble getting it to run on Windows 7.
It doesn't look like you are providing a database file on the startline in the ODBC configuration. Are you providing this somewhere else? What does your actual connect string look like in the application?
Version 12 will probably not work, since your application was written for version 5. However, to even have a chance, you have to rebuild the version 5 database in version 12 format and then replace the SQLA version 5 ODBC data source with a version 12 one with the same name.
Is this an application that you/your company wrote or is it a third party app. you purchased? Is it a 16 or 32 bit application?
Also, I would suggest setting the application up to run in compatibility mode as well as running it as an administrator.
I'm having issues with redemption because Outlook 32 bit can be installed on a 64 bit machine. The RedemptionLoader doesn't determined the bit version of Outlook installed on a 64 bit machine. Has anyone run into this before?
The problem is that you can't use 32 bit DLLs in 64 bit processes. But there's a workaround I've found after a long period of search.
It's possible to run the 32 bit Redemption-DLL in a 32 bit DllHost.exe process. Now you're able to access this DllHost.exe*32 by your x64 or AnyCPU application, because THAT is possible.
That sounds complicated but is relatively simple.
First register your Redemption.dll (x86) on the system. I've done it this via:
regsvr32.exe "C:\Program Files (x86)\Redemption\Redemption.dll"
If you start your application without registering the Redemption.dll you'll get an exception like:
COMException: Retrieving the COM class factory for component with CLSID {29AB7A12-B531-450E-8F7A-EA94C2F3C05F} failed due to the following error: 80040154 Klasse nicht registriert (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
Once the 32 bit DLL ist registered you need to add some keys and values to your Registry.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Wow6432Node\AppID\{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}]
"DllSurrogate"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}]
"AppID"="{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\AppID\{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}]
"DllSurrogate"=""
What's now happening when start your application is that the system starts a DllHost process which loads the Redemption.dll in a x86 environment. You will see a dllhost.exe*32 with a COM Surrogate description on task manager, after you've started your x64 application. All accesses to Redemption.dll will now be routed to the DllHost.
Of course you have to add these registry keys only on x64 systems with a x86 Outlook client ;)
Hope this will help some of you :)
RedemptionLoader does not determine Outlook bitness because it won't do you any good: it determines the bitness of the calling process and loads the appropriate version of Redemption (32 vs 64 bit), but that can raise an error if the bitness of your process/Redemption is different from the Outlook bitness. A 32 bit dll cannot be loaded by a 64 bit process.
See http://www.dimastr.com/redemption/faq.htm#ErrorCreatingRedemptionObject for more details.
It is possible to load a 32 bit DLL in a 64 bit PowerShell session. See my answer here for more details.
In short, you can use Start-Job -RunAs32 which loads a 32 Bit PowerShell version
im trying to connect to to an interBase database, and create a ASP.net application.
im using a 64bit machine but for sum reason I cant seem to add the data source from the data source administrator. im using a program called data direct which worked perfectly on my 32bit machine.
can any one suggest how I may be bale to solve this ??
Although there is (as of IB XE) a 64 bit client for IB, I don't think Embarcadero/DataDirect currently ship a 64 bit ODBC driver. Therefore you would need to use a 32 bit app pool and set up the data source using the 32 bit ODBC control panel (or directly in the 32 bit registry). This will work on a 64 bit machine.
I agree with Craig.
But a bit suggest:
You can step the ODBC creation, by using directly and odbc.odbcConnection:
$ Dim sConnStr As String
$ sConnStr = "Driver={INTERSOLV Interbase ODBC Driver (*.gdb)};
$ uid=sysdba;
$ password=masterkey;
$ database=server:path"
$ Dim oConn As New Odbc.OdbcConnection(sConnStr)