I want to be able to migrate DBISAM4 databases to EDB from ADO.NET.

I have copied "edbmigratedbisam4.dll" from the
"libs\edbmigratedbisam4unicode" folder into my EDBConfig folder.

I can now migrate databases successfully using the ElevatedDB Manager,
however, the presence of "edbmigratedbisam4.dll" in my EDBConfig folder
causes the ADO.NET provider to fall over.

The moment I call "con.Open();" for the first time, I get
System.NullReferenceException {"Object reference not set to an instance of
an object."}

The stack trace is as follows :-

  at Elevate.ElevateDB.Data.Engine.TEDBLogEvent.set_Category(Int32 Value)
  at Elevate.ElevateDB.Data.Engine.TEDBLocalSessionManager.LogEvent(Int32
EventCategory, Int32 EventFunctionCode, Int32 EventErrorCode, String
EventDescription)
  at
Elevate.ElevateDB.Data.Engine.TEDBLocalSessionManager.HandleException(Exception
E, Int32 FunctionCode)
  at
Elevate.ElevateDB.Data.Engine.TEDBLocalSessionManager.ModuleLoadError(Exception
LoadException)
  at Elevate.ElevateDB.Data.Engine.TEDBModule.DoLoadError(Exception
LoadException)
  at Elevate.ElevateDB.Data.Engine.TEDBModule.LoadModuleInstance() <<
problem line?
  at Elevate.ElevateDB.Data.Engine.TEDBModule.GetModuleType()
  at Elevate.ElevateDB.Data.Engine.TEDBModule.get_ModuleType()
  at
Elevate.ElevateDB.Data.Engine.TEDBLocalSessionManager.LoadConfigModules()
  at Elevate.ElevateDB.Data.Engine.TEDBLocalSessionManager.Initialize()
  at Elevate.ElevateDB.Data.Engine.TEDBLocalSessionManager.Open(String
SessionProcessName, String SessionName, String SessionDescription)
  at Elevate.ElevateDB.Data.Engine.TEDBConnectionManager.Connect()
  at Elevate.ElevateDB.Data.EDBConnection.Open()
  at WindowsApplication2.Form1..ctor() in
E:\vs\source\ElevateDB_Test\WindowsApplication2\Form1.cs:line 33
  at WindowsApplication2.Program.Main() in
E:\vs\source\ElevateDB_Test\WindowsApplication2\Program.cs:line 17
  at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
  at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
  at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
  at System.Threading.ThreadHelper.ThreadStart()

If I delete the "edbmigratedbisam4.dll" file from the EDBConfig folder -
everything works fine.

My guess is that the problem lies in
Elevate.ElevateDB.Data.Engine.TEDBModule.LoadModuleInstance() when loading
the unicode version of "edbmigratedbisam4.dll".

I double-checked that I am *definitely* working with the unicode version of
the dll, which I must be as I can correctly convert databases in the Unicode
ElevateDB Manager and then access them via ADO.NET.

Any thoughts?

Hedley,

<< I want to be able to migrate DBISAM4 databases to EDB from ADO.NET.

I have copied "edbmigratedbisam4.dll" from the
"libs\edbmigratedbisam4unicode" folder into my EDBConfig folder.

I can now migrate databases successfully using the ElevatedDB Manager,
however, the presence of edbmigratedbisam4.dll" in my EDBConfig folder
causes the ADO.NET provider to fall over.

The moment I call "con.Open();" for the first time, I get
System.NullReferenceException {"Object reference not set to an instance of
an object."} >>

I'll check it out.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hedley,

<< I can now migrate databases successfully using the ElevatedDB Manager,
however, the presence of "edbmigratedbisam4.dll" in my EDBConfig folder
causes the ADO.NET provider to fall over.

The moment I call "con.Open();" for the first time, I get
System.NullReferenceException {"Object reference not set to an instance of
an object."} >>

I have tried this and traced it through the EDB Data Provider, and it works
just fine with a test VS app and 2.02 B7 of the EDB Data Provider.  I'm
using the Unicode edbmigratedbisam4.dll shipped with 2.02 B7.

Here's the code I'm using:

private void button1_Click(object sender, EventArgs e)
{
EDBConnectionStringBuilder csb = new EDBConnectionStringBuilder();
csb.Type = "LOCAL";
csb.ConfigPath = @"C:\unicode";
csb.Database = "ADOUnicodeTest";
EDBConnection conn = new EDBConnection(csb.ConnectionString);
try
{
conn.Open();
}
finally
{
conn.Close();
conn.Dispose();
}
}

During the connection open, internally, the migrator module gets loaded, it
checks out okay, and it is unloaded.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

I created a new blank project, tried your code and got the some same
problem. As soon as I removed the unicode edbmigratedbisam4.dll ... no
problem.

My development PC is :-

Core2Duo Q6600
4Gb RAM
Windows XP Pro x64
Visual Studio 2008 (SP1)
ElevateDB 2.02b7

HOWEVER, I then tried the exact same code on my laptop... and it worked
fine!!?

Core2Duo T7500
3Gb RAM
Windows Vista Business 32bit
Visual Studio 2008 (SP1)
ElevateDB 2.02b7

Could it be something to do with WinXP x64? I know WinXP x64 isn't very
common but Vista x64 is getting more common. I wonder if anyone can try
testing this on another x64 machine to see if that's the cause?

Many thanks!

That previous post was me again - sorry about the name - I posted it from my
laptop.
Hedley

Hedley,

<< Could it be something to do with WinXP x64? I know WinXP x64 isn't very
common but Vista x64 is getting more common. I wonder if anyone can try
testing this on another x64 machine to see if that's the cause? >>

It most likely isn't specific to WinXP x64, but rather to 64-bit OSs in
general.  More than likely there's a default word size issue somewhere that
is causing the interface to fail.  I'm going to have to dig some more to
figure this out.

--
Tim Young
Elevate Software
www.elevatesoft.com

> It most likely isn't specific to WinXP x64, but rather to 64-bit OSs in
> general.  More than likely there's a default word size issue somewhere
> that is causing the interface to fail.  I'm going to have to dig some more
> to figure this out.

Ok Tim - if I can be of any assistance please let me know - I'll be happy to
test it for you if you don't have a 64bit OS available.

Regards,

Hedley

Hedley,

<< Ok Tim - if I can be of any assistance please let me know - I'll be happy
to test it for you if you don't have a 64bit OS available. >>

Okay, the issue is the 64-bit process calling the 32-bit DLLs.
Unfortunately, there's nothing we can do about this short of setting the EDB
Data Provider's assembly CPU flag to X86, thus meaning that you also have to
set your application to use the X86 CPU target in order to use the EDB .NET
Data Provider.  This is at least until Delphi gets a 64-bit compiler and we
can compile the migrators as 64-bit DLLs.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hmmm...

Well if I compile my app for x86 it works fine. However, I don't really want
to restrict my app to 32bit, so I guess the best thing I can do is code a
Delphi utility program which accepts command line parameters to upgrade the
database.

Thanks for looking into this Tim.

Ah... further to my previous ingenious idea... .NET uses UNICODE, I've got
D7 and I can't see any obvious way of making the EDBEngine connect to a
UNICODE EDBConfig file?

Is there a quick way of doing this in D7, or will I need to write this
utility in .NET?