My application is in classic asp. Till now it is working fine with 32bit windows server and connecting oracle via a system DSN which is prepared with "Microsoft ODBC driver for oracle".
Now, the server has been migrated to 64bit Windows server 2008 R2. We have some third party dlls, which also have 64bit available. So, I deploy the application in IIS 7.5 and it is working fine.
In new server, I am using Oracle driver, as for 64bit, there is no driver of "Microsoft ODBC Driver For Oracle". Everything is working fine, except, when I try to fetch a record-set, it is returning nothing. No Error message, no data, nothing is coming.
Also, I can't change the app pool compatibility with 32 bit to "True", because, there are some third-party component which will only work in either of one environment. Either 32 bit or 64 bit.
So, my concern is, whether I can work with both the DSN[32 and 64]? OR any other idea to run the application.
Could you use an OLEDB driver instead. Oracle certainly provide a 64 bit OLEDB driver, and it could well be installed on your server already.
http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html
Here's another useful link, with a very friendly URL
http://www.connectionstrings.com/oracle/
ODBC isn't generally regarded as the best way to go, unless you're using MySQL when it's pretty much your only option
Related
I've installed Firebird 3.0.3 Classic Server 32-bit on a newly setup Windows Server 2016 (32-bit because I have to use a legacy UDF dll that's only available in 32-bit). Except for the 64-bit ODBC connection, all connections work fine from client machines (32-bit ODBC connection, FlameRobin). But when I try to access the database through the 64-bit ODBC DSN, I get the error "your username and password are not defined".
My client machine in this case is a Windows Server 2012 R2. I've done the following steps:
install the 32-bit Firebird Client libraries (version 3.0.3)
install the 64-bit Firebird Client libraries (version 3.0.3)
install the 32-bit ODBC driver (version 2.0.5.156)
install the 64-bit ODBC driver (version 2.0.5.156)
open the 32-bit Windows ODBC administration console and create the DSN - connection test OK
Screenshot: https://postimg.cc/WDrJQryH
open the 64-bit Windows ODBC administration console and create the DSN - connection error!
Screenshot: https://postimg.cc/5XDC7psz
I'm sure I haven't missspelled the password. What could I have missed? Thanks a lot!
In general problems like this (when you have two almost identical applications and only one of them working) are often diagnosed by comparing their behavior and looking for differences, then trying to change computer or application setting to eliminate suspicious and unneeded differences unless both program work. A useful tool for it would be for example SysInternals Process Monitor, which can be set to record files I/O tracks (also registry and other things), which can give a valuable insight into program implementation and its failure. In this particular case when u press "test connection" buttons in ODBC32 and ODBC64 windows the track of files and registry accesses would probably highlight where things start go wrong for 64-bits application in contrast with the 32-bits one.
If to skip systematic diagnostic for a while and try mere guessing, then Mark suggests that the 64-bit app fails to locate the proper fbclient.dll (where proper might mean many things: FB version, 32/64-bitness, textual configuration files and what not).
Seeing your ODBC setup windows have an explicit fields "Client" with "Browse" button I make a guesstimation that ODBC tries to auto-locate the client library and for some reason locates some unlucky one.
Then I suggest you to try to set that "Client" field to precisely the fbclient.dll file that the Firebird engine itself uses, and if you did not changed default installation settings it would be something like something like "c:\Program Files\Firebird\Firebird_3_0\bin\fbclient.dll"
I have developed ASP.Net application which is connecting to Oracle Database using ODBC via DSN connection.
Everything works on my local development environment but after I deployed in IIS, it is unable to connect to database & logs below error.
***[IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified***
Then I started looking for solution & tried below things but nothing worked.
Checked the application is developed using Platform Any CPU.
DSN is configured & Tested Connection using Oracle client 64 bit ODBC Data Source. On 64 bit server DSN can be configured for 64 bit & 32 bit also.
Tried with setting permissions to DSN in registry for the apppool identity user.
Tried AppPool Setting for Enable 32Bit Application to True, in this case it give another error that ODBC & application architecture mismatch.
Please let me know if any more alternative is there, otherwise I am thinking of installing 32bit oracle client & try to connect using 32bit ODBC DSN.
Thanks for your help in advance.
Found this link very helpful.
https://support.microsoft.com/en-in/kb/942976
It says about the visibility of DSN connections for 32bit & 64bit applications.
Tried with small test utility (winform) & the behaviour for 32bit & 64 bit application can be distinquished.
But unable to find the solution for ASP.Net application.
I have built the code using X64 platform & then deployed it in IIS.
I was using 11.2.0 client so it started reading the DSN but Arithmetic operation resulted in an overflow exception. This is issue in the driver need to install the patch.
https://blogs.msdn.microsoft.com/mariae/2012/07/05/arithmetic-operation-resulted-in-an-overflow-error-running-a-report-that-uses-a-connection-data-source-to-oracle-10/
I have a classic ASP application which I've moved from a Windows 2003 server running IIS6.0 to 64-bit Windows 2008 R2 running IIS7. In IIS7 I've created a website and added an application to that and have set the application pool to enable 32-bit applications.
The application connects to an Oracle database using the ORAOLEDB driver - I've installed the 64-bit Oracle client 11.2.0.3 to connect to the backend Oracle 11g database and can connect fine via the same user as the application using SQLPlus.
When I run the application though, its attempt to connect to Oracle fails with the IIS logs showing the error:
"Provider cannot be found. It may not be properly installed"
I've tried various possible things to try and get this working:
registering OraOLEDB11.dll manually
disabling 32-bit applications from the app pool
using the 32-bit drivers instead both with 32-bits apps enabled and disabled
reinstalling the drivers completely and trying all the above
So far without any luck. The asp code connects as follows:
objOracleConnection.CursorLocation = adUseClient
objOracleConnection.ConnectionString = "Provider=OraOLEDB.Oracle;Data Source=MYDATASOURCE;User ID=USER;Password=PASSWORD;PLSQLRSet=1;OLE DB Services=-2;"
objOracleConnection.Open
EDIT: I've tried a simple VBS script (using essentially the same code as above) to connect and it gets the same error, so IIS may not be the problem. The exact same script works on the Windows 2003 box however.
I've reinstalled the Oracle client via the 'Troubleshoot Compatibility' option, indicating that the application works under Windows 2003 SP1 but still get the same issue from both the VBS script and the IIS application :(
This is an educated guess, but enabling 32 bit applications in IIS7 seems to disable 64 bit applications. If it's a 64 bit driver you may need to disable 32 bit in your app pool
I Have an asp.net web service that uses an oracle database. It works when I run it locally but when I upload to the server it gives me ORA-1017. The project on the server is an identical copy of what I have on my local computer, so the password is the same. I tried to install Oracle client 11g r2 because I have been told that the other (don't know which one) oracle client converts the password to uppercase. I don't have much experience with oracle and don't know what is wrong. Any help is appreciated.
The server is Windows Server 2003 32bit, the oracle version is Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production . The oracle server is on another machine.
Update1:
It works now. I reinstalled the oracle client from here. I selected Administrator at the beginning, it seems it matters. There were also 2 clients installed on the server so probably that created problems also, I'm not sure. One client should be enough, it can connect to all oracle versions. This should also work with ODAC as suggested by Andy Arismendi. There is also an (confusing, at least for me) answer here about connecting to oracle that suggests oracle instant client (I think).
So the 3 packages are:
Oracle Client (3rd download link from the top)
ODAC
Oracle Instant Client
You should install only one of these. I don't know the difference between them. It seems they contain similar components.
This doesn't directly address your question but have you looked at ODAC Oracle Data Access Components? This is a .NET library you can use to access the database.
This is a good walkthrough for how to use it. http://www.oracle.com/technetwork/articles/dotnet/vs2010-oracle-dev-410461.html
Passwords in versions prior to Oracle 11g were case-insensitive - 11g upwords supports case sensitive passwords. If the server was upgraded from 10g to 11g - the passwords remain case-insensitive till they are changed.
So I'd say try changing the password.
It works now. I reinstalled the oracle client from here. I selected Administrator at the beginning, it seems it matters. There were also 2 clients installed on the server so probably that created problems also, I'm not sure. One client should be enough, it can connect to all oracle versions. This should also work with ODAC as suggested by Andy Arismendi. There is also an (confusing, at least for me) answer here about connecting to oracle that suggests oracle instant client (I think).
So the 3 packages are (ordered by size descending ):
Oracle Client (3rd download link from the top)
ODAC
Oracle Instant Client
You should install only one of these. I don't know the difference between them. It seems they contain similar components.
I have a freshly built 64-bit Windows Server 2008 R2 box that I have installed 64-bit Coldfusion 9 Standard on. I've upgraded and hotfixed it up to the most current version of CF. I also had 64-bit Oracle 11g (11.1.0.7.0) Client installed on the box. I've created a System DSN using the 64-bit ODBC Data Source Administrator in Windows and can successfully test the connection of the data source.
All of these installations went smoothly, however, when I went to add a datasource in the Coldfusion Administrator I receive the error:
Connection verification failed for data source: myDatabaseName
java.sql.SQLException: [Macromedia][SequeLink JDBC Driver][ODBC Socket]internal error: The specified DSN contains an architecture mismatch between the Driver and Application
The root cause was that: java.sql.SQLException: [Macromedia][SequeLink JDBC Driver][ODBC Socket]internal error: The specified DSN contains an architecture mismatch between the Driver and Application
I am having a hard time understanding exactly where this architecture mismatch is coming from since the box is entirely 64-bit. I see while looking at all the processes that are running, some related CF processes are running in 32-bit (Verity related processes, SOLR and CFDotNetSVC). I am not sure if those could cause this issue but I am at a loss to explain were this mismatch would come from otherwise.
Anyone have any ideas?
Using Dan's advice I grabbed a JDBC Driver from Oracle here:
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-111060-084321.html
I then moved the JAR (ojdbc6.jar in my case) and added it to my Coldfusion Class Path.
Determining the correct settings for using the datasource to Coldfusion was slightly harder but here are the settings I ended up going with:
JDBC URL: jdbc:oracle:thin:#//dbsrv.mydomain.com:1521/myDB.world
Driver Class: oracle.jdbc.driver.OracleDriver
Driver Name: Oracle Thin Driver
Then the username and password for the DB.
Sure enough it worked like a charm.
Dan, I want to give you a check mark because you definitely put me in the right direction, but I can only mark one correct.
I believe you need to either step down to the 32-bit drivers, or use native JDBC drivers to connect to Oracle successfully. My suggestion would be to go the JDBC route, and connect directly through a native Oracle JDBC driver by using the "other" selection on the Datasource screen. You'll get better performance that way, and have more control over your connection via ColdFusion.
Connecting to Oracle information in ColdFusion Livedocs.
i found an alternate way to do this
install the ODBC drivers for 64bit and 32bit (in that order) on your win2008 64bit OS
thereafter create the DSNs on both the System32 folder and SysWow64 folder by running the odbc32ad32.exe
ensure your tnsnames are setup fine in the respective network/admin folder (if you use tnsnames to maintain your sids)
now on the CF admin you creaet a new ODBC source with aODBC Socket and name. the next page should show you a drop down of all DSNs that exists in the 64bit DSN setup. When you go and test it in CF, it will strangely use the config of the 32bit DSN setup for validationb
voila....your connections should work. No worries of those architectural failures etc
We needed to setup 64 bit ODBC connections for a ColdFusion 11 server to query against 2012 SQL Server instance on Windows 2008 R2 Server. The ODBC connections would show up but would never work. We received so many various messages when verifying such as "needing SSL connections to work" and also timeout messages as it was having problems logging into SQL Server.
I stumbled across this post and we decided to follow setting up 64bit ODBC connections and then effectively overwriting them--preserving the name using the 32bit ODBC. Thank you again fellow developers, especially Souzam! My instructions are below:
For Windows 2008R2 Server you must disguise 64bit ODBC socket configurations for 32 bit in order for them to appear in CF Admin as datasources (obvious bug in CF 11):
Creating 64bit ODBC connections via 2008 R2 ODBC application, follow a naming convention that will allow you to recall in 32 bit configuration.
Configure ODBC 32bit connection in SYSWOW64 (C:\Windows\SysWOW64) using the odbcad32.exe using the previous 64bit names in Step #1.
Create data sources in CF Admin as these should appear in a dropdown when creating ODBC Socket Type connections.