odp.net

My development team is experiencing numerous ORA-12571: TNS:packet writer failure errors using ASP.NET 3.5 and 4.0 against Oracle 11g. These errors are inconsistent as to when they occur, and are generated by numerous applications. This exception happens while calling random stored procedures, packets, and inline SQL statements. The Oracle 11 client is installed on the web server. Some applications use Microsoft System.Data.OracleClient to connect to Oracle, and some use the .NET components provided by oracle (ODP.NET). Both data access objects come up with the same error. There are other non

I installed the odp.net 32 bit installation for Visual Studio 2012. I set a reference to the Oracle.DataAccess.dll and my connection to Oracle seems to be working. When I build the project (.net 4) I get the following error. The project is set to build AnyCPU (my workstation is 64 bit and the server where we will ultimately deploy to is 32bit) 'There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference Oracle.DataAcess, Version 4.112.3.0, Culture=neutral, PublicKeyToken=89b483f429c47342, processorArchitecture=x86,

As part of an effort to stop using dynamic SQL generation and encourage use of bind variables, I am running into some problems. I am querying an Oracle 9i database from an ASP.NET page using Oracle Data Providers for .NET The query is sql = "SELECT somedata FROM sometable WHERE machine = :machineName "; I define the Oracle Parameter as follows OracleParameter parameter = new OracleParameter(); parameter.ParameterName = "machineName"; parameter.OracleDbType = OracleDbType.Varchar2; parameter.Value = machine; //machine is a variable of type string parameterList.Add(parameter); This works fine

I am trying to develop an ASP.NET MVC 4.0 application using Oracle 11g Express and the .NET 4.0 framework. I can connect to the DB using the ODP.NET provider and can also generate my EDMX against the database. What I can't do is query the underlying DB using entity framework. When instantiating my DbContext using the connectionString Visual Studio generated, I get the following error: Unable to find the requested .Net Framework Data Provider. It may not be installed However, it is installed because I can see the dll in the GAC. It is mentioned in machine.config. It is referenced by my project.

I am using Oracle.ManagedDataAccess Nuget Package Version 12.1.022 in my C# (.NET 4.0) project. The package automatically creates entries in the app.config file. How can I read the datasource string from this file to be able to connect to the data base? System.Configuration.ConfigurationManager.AppSettings.Get("dataSource"); is not working for me <?xml version="1.0" encoding="utf-8"?> <configuration> <configSections> <section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken

When I try to execute a create procedure using ODP.NET I get back ORA-24344: success with compilation error. However, when I run the same statement in SQL Developer it compiles successfully. Does anyone know what I need to change to get my procedure to compile? Is it a character set issue? I am using Oracle 10g Express, .NET 3.5 SP 1, and ODP.NET 2.111.7.20 (version from Oracle.DataAccess.dll) [TestMethod] public void OdpNet_CreateProcedure() { ConnectionStringSettings settings = ConfigurationManager.ConnectionStrings["ODP.NET"]; using (var con = new OracleConnection(settings.ConnectionString)

I want to deploy a client application that uses Oracle's ODP.net but I don't want to install ODP.net on every machine. Rather I'd like to copy the managed dll oracle.dataaccess.dll on every machine and have the native dlls on which it depends available, on a shared disk. By decompiling the oracle.dataaccess.dll code I have seen that it calls a method that gets the location of the native dlls from the registry. So, in addition to copying the oracle.dataaccess.dll on every machine I would have to add the registry keys that would point to the native dlls on the shared disk. My question: does one