Specs (Production machine): LLBLGen Pro version 2005 (latest). Oracle 10g x64 Xeon processor ODP.net version 10.2.0.2.21 .NET 2.0 c#

(development machine that compiles project is 32 bit)

I have been testing the much awaited x64 Odp.net (beta) found here:

http://www.oracle.com/technology/software/tech/windows/odpnet/64-bit/index.html

PROBLEM:

When performing a save() like this:

MyTest.AbcEntity abc = new MyTest.AbcEntity();
abc.Text1 = "Hello World";
abc.Save()

SD.LLBLGen.Pro.OrmSupportClasses.NET20 fails to connect, giving back the infamous "ora-12154" (http://ora-12154.ora-code.com/) error after attempting Commit() inside the entity's Save() implementation.

Reasons I Think I Have Done Things Correctly:

1. The Oracle.DataAccess.dll is installed on x64 machine (version 10.2.0.2.21)

2. I have include this in the app config in order to cause the new .21 to be used:

<dependentAssembly>
    <assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342"/>
    <bindingRedirect oldVersion="2.102.2.20-10.2.0.100" newVersion="2.102.2.21"/>
</dependentAssembly>

1. I have tested a non-llblgen console application on same machine as oracle 10g using the identicle connection string with successful sql command execution to ensure ODP.NET x64 and oracle 10g are in proper working order.

Thoughtful replies would be appreciated.

All LLBLGen Pro does is creating an OracleConnection with the connection string you specified.

Could you test it with a small console application you write yourself with OracleConnection and the connection string as specified in the .config file?

Like i said in item 3 above, I tested with that to see if odp and oracle were in place

This works fine on the x64 machine, where app config uses binding redirect. (this uses input file for string, llbl app uses the <add key="Main.ConnectionString" value="data source=????;user id=????;password=????;persist security info=false;Connection Lifetime=500;Connection Timeout=500;"/>

using System;
using System.Collections.Generic;
using System.Text;

using Oracle.DataAccess.Client;
using System.Data;
using System.IO;

namespace DatabaseTest
{
    class Program
    {
        static string connectionString = "";

        static void Main(string[] args)
        {
            if (args.Length == 0)
            {
                Console.WriteLine("missing connection string file");
                return;

            }

            if (!File.Exists(args[0]))
            {
                Console.WriteLine("file does not exist: " + args[0]);
                return;
            }



            TextReader tr = new StreamReader(args[0]);

            connectionString = tr.ReadToEnd();

            Test();

            Console.ReadLine();

        }

        public static void Test()
        {
            OracleCommand testCmd = new OracleCommand();

            testCmd.Connection = new OracleConnection(connectionString);

            testCmd.CommandText = "select count(*) Count from user_tables";

            OracleDataAdapter adapter = new OracleDataAdapter(testCmd);
            DataSet ds = new DataSet();
            
            adapter.Fill(ds);

            if (ds.Tables.Count > 0)
            {
                Console.WriteLine("User tables count: " + ds.Tables[0].Rows[0]["Count"].ToString());
            }

            

        }
    }
}

Is the schemaName the same on the x32 machine and the x64 machine?

Would you make a test, create an LLBLGenPro project that targets the database on the x64 machine, so the code is generated against this database, and check to see if it works correctly, (you can save an entity)?

The llbl app works fine executing on x32 bit machine. It saves the entity to database on x64 machine with no errors.

To summarize: LLBL App on x32 -> write to database on x64 --- OK Test App posted above on x32 -> write to database on x64 --- OK

LLBL App on x64 -> write to database on same x64 --- ERROR Test App posted above on x64 -> write to db on same x64 --- OK

All uses the same schema name on both places, I even watched watched the DbUtils on x64 machine handle the correct connection string.

I will create an llbl gen project against the x64 db server to see it that makes a difference, though I doubt it.

Ok, time to enter the Twilight Zone!!

I do not understand this, but I got it working.

By moving the application from one directory to another directory (on same drive letter), it causes Oracle.DataAccess to stop giving an error.

The first impression of this being an LLBL issue was because my non-llbl test app was sitting in an entirely different directory, working nicely.

If i place the non-llbl app in the adjacent directory of the llbl app, it gave same error.

Whether this is because of the midas touch of mine when it comes to Oracle, or that fact that this is ODP.NET beta x64, I don't know.

Thanks for the input guys.

Error only happens when running from the "Program Files (x86)" directory in windows XP, works anywhere else.

very strange.... well at least I'm glad you got the mistery solved !