What I can observe:
I am using windows 7 64bit My code (establish an odbc connection with
a SQL server on the network, simple reading operations only) is
written in python 3.6.2 32bit
I pip installed pyodbc, so I assume that was 32bit as well.
I downloaded and installed the 64bit "Microsoft® ODBC Driver 13.1 for SQL Server®" from microsoft website.
My python code connects to
other computers on the network, which run server2003 32bit and either SQL Server 2005(32bit) or sql2008(32bit).
The setup works.
Moreover: cursory test shows that, the above setup can successfully connect to a computer with Microsoft server2008(64bit) running sql2012(64bit) with the configuration under "SQL Server Network Connection (32bit)" being empty (meaing, the 32bit dll is missing), while the default 64 bit network connection configuration contains the usual config options like ip adress and listening port info.
My own explanation:
[1] the client and the server's OS and ODBC interfaces can be of any 32/64 bit combination, but the protocol that travels thru the network between my computer and the sql computer will be identical.
[2] 32 bit python+pyodbc can talk to microsoft's 64bit odbc driver, because... 32 bit python knows how to use a 64 bit DLL...?
A 32bit application can NOT invoke a 64bit dll, so python 32bit can not talk to a 64bit driver for sure.
msodbc driver for sql server is in essence a dll file: msodbcsql13.dll
I just found out (which is not even mentioned by microsoft) that "odbc for sql server 13.1 x64" will install a 64bit msodbcsql13.dll in system32 and a 32bit msodbcsql13.dll in SysWOW64 ( 32bit version of "system32" on a 64bit windows system)
I can not however be certain that the network protocol between a 32bit client talking to 64bit sql server will be the same as a 64bit client talking to a 64bit sql server. But, I believe that, once a request is put on the network by the client to the server, 32bit or 64bit doesn't matter anymore. Someone please comment on this
Related
We're in the process of converting our two FoxPro systems to new technology, but meanwhile we need to upgrade our server and I am trying to find out whether our legacy systems will run there. We'd prefer to go to Windows Server 2019, but using Server 2012 is possible. Our stations are Win 7 or 10 Pro, some 64-bit.
One system is in Visual FoxPro 9 and uses its native DBFs and some DBFs in FPD 2.6 format. Certain graphical and document functions (e.g.: OCR) are performed by calls to LeadTools 12.0. The application also calls Outlook.
The second system is a single-user application in FoxPro for DOS 2.6 run from an .app file. The 32-bit stations run this natively, while the 64-bit stations use the product, vDOS, to allow the 16-bit FPD to run there. The application wants to reside on the server since multiple stations can run it, albeit at different times.
Any help is much appreciated. Thank you!
Will a Visual FoxPro 9 EXE run on those server operating systems? Yes.
Will a Foxpro For DOS or FoxPro for Windows EXE run on those server operating systems? No. Those flavours of FoxPro are 16-bit, and as such would require a 32-bit version of Windows Server, the last of which was Server 2008.
However I suspect you are not running either of these on the server. You have a shared folder on the server with the DBFs in it, and the executables are running on workstations.
So if you have a 64-bit OS on the workstation then you can only run the Visual FoxPro exectuable directly. If you had a 32-bit OS on the workstation, you can run both Visual FoxPro and FoxPro for DOS\Windows executables.
Your question is really 'can I put the DBFs in a shared folder on those server operating systems and access them from client workstations?', and yes you can.
I'm trying to connect my Excel to Oracle with this connection string in VBA:
dim cn As New ADODB.Connection
cn.Open "Provider=OraOLEDB.Oracle;Data Source=source;User Id=userid;Password=pwd;"
I'm getting this error:
Run-time error '3706':
Provider cannot be found. It may not be properly installed.
Relevant references:
Microsoft ActiveX Data Objects 6.1 Library
OraOLEDB 1.0 Type Library
Excel is MS Office Professional Plus 2010 64-bit
Windows is 7 Enterprise, service pack 1, 64 bit
Oracle client is 11.2.0 32 bit (I think)
Oracle server is Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
Now... I have scoured the net and cannot figure out what the issue is, but my best guess is there's some 32 bit vs 64 bit conflict with drivers I'm using. I'm trying to get a sense of what path I should be taking before I involve my company's IT department to try installing stuff for me. Does the Oracle client have to be 64 bit if MS Office is? Or do I just need the 64 bit Oracle Data Access Components? I've tried a bunch of different connection strings with no success, including using MSDAORA instead of OraOLEDB.Oracle...
Yes, when you use 64-bit Excel you must install also 64-bit Oracle Client and 64-bit OLE DB Provider.
OLE DB Provider from Microsoft (i.e. MSDAORA) does not exist for 64-bit. It exists only for 32-bit and has been deprecated for very long time already.
I don't know whether you need your 32-bit Oracle Client for something else, so maybe you cannot simply remove it from your PC. Here is an instruction how to install both 32-bit and 64-bit Oracle Client on one machine.
Install Oracle Client x86 and x64
I too had the same issue and the solution is to set the oracle drivers for the excel session to 32 Bit drivers and initiate the excel.
I use the following Bat file to open the excel and it connects to oracle without any issues:
#
Set Temp=C:\Temp
Set TMP=C:\Temp
Set Oracle_Home= #YourDriveLetterhere - >M:\ORA12C\product\12.1.0\client_1
Set Path=C:\Windows;C:\Windows\System32;M:\ORA12C\product\12.1.0\client_1\bin;M:\ORA12C\product\12.1.0\client_1\nls\mesg;M:\ORA12C\product\12.1.0\client_1\network\admin;
START "" "C:\MacroFileNameWhichConnectsToOracle.xlsm"
#
The oracle server matters not.
Try opening a dos window and type c:\ tnsping yourservername
look towards installation issues.
I know similar questions have been answered before, but I can't seem to clear my particular problem.
The architecture mismatch exception is prompted when Db-driver and VS-project have different platform targets (32, 64 bit). So far so good.
First thing I tried:
I changed my platform targets for my whole solution to 32 and after that to 64 bit.
-> same error in both cases (I'm not sure under which circumstances VS considers a project to be of a specific architecture, though. Maybe someone can elaborate on this point...)
Now I focused on the driver and DSN for Virtuoso 7.1.
Following the instructions for installing of the open source version of Virtuoso (link), I registered the driver in /lib using 'regsvr32 virtodbc.dll'. This promptly added it as a 32-bit Driver (visible when using the system32/odbcad32.exe). Using this driver in a DSN provided the architecture mismatch.
I tried to register the same dll as a 64 bit driver using the 64 bit version of regsvr32 without success. Since I can not add a suitable 64-bit DSN I would be content in using the 32-bit target cpu. As described the seemingly 32-bit versions of the virtodbc.dll are causing a architecture mismatch under any target platform configuration in VS.
I even installed the Client Connectivity Kit (link) which claim to provide only 64-bit drivers. Only to find out that the automatically installed drivers and DSN are also featuring as 32-bit drivers (meaning: they are only visible when using the 32-bit version of odbcad32.exe and not the 64-bit version)
I'm not sure where the problem lies (VS or Virtuoso drivers) and I would be thankful for your suggestions.
I think, you could try to install 32-bit ODBC driver from Virtuoso 6.4 Client Connectivity Kit.
p.s.
64-bit ODBC app requires 64-bit ODBC driver (and 64-bit ODBC driver manager)
32-bit ODBC app requires 32-bit ODBC driver (and 32-bit ODBC driver manager)
You can not mix them.
I am not quite sure I understand what your problem was or is ?
What is the bit'ness of your Visual Studio installation i.e. 32 or 64 bit ?
system32/odbcad32.exe is the 64bit ODBC Driver Manager despite the "system32" reference, which is a historic folder Microsoft retained from the 32 bit Windows days, placing the actual 32bit binaries on a 64bit system in sysWOW64 folder.
To make things even worse in the last 64bit Visual Studio I used the development environment is actually 32bit and the deployment is 64 bit, requiring a 32 & 64 bit driver for development and deployment, see http://wikis.openlinksw.com/dataspace/owiki/wiki/UdaWikiWeb/MsSqlOn64bitWin
As Virtuoso 7 is only available in 64bit form and the Virtuoso 6 ODBC Drivers (and data access client in general) are compatible with Virtuoso 7 server, you can install the Virtuoso 6 commercial (as Sergei mentioned) or open source (http://bit.ly/1A3mCje) 32 & 64 bit ODBC Drivers and VS should then just work as it has one for development and one for deployment.
I am having an application that is running on IIS with Enabled 32 bit Application.
In a remote server(connection available in local machine),i have installed Pervasive SQL.
I have installed Pervasive SQL Driver in local machine and trying to connect the database "TestApplication" in Pervasive SQL.
For that I have created System DSN "DSNTEST", and tried with Windows Application.Its working fine.
But i couldnt connect to the database from Web Site.
An error occured "Error: ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application".
Can anyone please help me to resolve this?
Thanks in advance.
It sounds like the ASP.NET application is trying to run as a 64 bit application. Because you're using PSQL v11, you can install the 64 bit ODBC driver which is part of the PSQL v11 64 bit client install (at http://www.pervasive.com/database/Home/Products/PSQLv11.aspx).
The other option is to make sure that the ASP.NET project is built with a target of x86 rather than x64 or AnyCPU.
I have to make an odbc connection to my database.
Problem is that when I compile my program it just sees drivers listed on odb admin 32bit, but drivers (oracle ones...) are listed under odbc admin 64bit so it gives me an "unrecognized driver" error.
How can I solve this problem?
Build your program for 64 bit to get access to 64bit ODBC APIs.