Hi!

I want to create a database and migrate a DBISAM2 database to ElevateDB (Unicode). All jobs must be executed at runtime. Please have look at the code. What is the best way to achieve this?

I get an exception (Index out of bounds) on creating the database - please see first statement in the code.
Stack trace:
  bei Elevate.ElevateDB.Data.EDBCommand.Prepare()
  bei Elevate.ElevateDB.Data.EDBCommand.Execute()
  bei Elevate.ElevateDB.Data.EDBCommand.ExecuteNonQuery()
  bei ElevateDB.Form1.MigrateBtn_Click(Object sender, EventArgs e) in ....

If the database is created via Elevate DB Manager (Unicode) i get the same exception on executing the second statement (CREATE MODULE...).

===================================
using (Elevate.ElevateDB.Data.EDBConnection connection = new
               Elevate.ElevateDB.Data.EDBConnection(@"CONFIGPATH=D:\Devtools\Projects\DotNet\TestProjekte\ElevateDB\DataBase;UID=Administrator;PWD=EDBDefault;DATABASE=Configuration"))
{
   try
   {
       connection.Open();
       using (Elevate.ElevateDB.Data.EDBCommand cmd = new Elevate.ElevateDB.Data.EDBCommand("", connection))
       {
           cmd.CommandText = @"
CREATE DATABASE ""MyDatabase""
PATH 'D:\Devtools\Projects\DotNet\TestProjekte\ElevateDB\DataBase\Data'
DESCRIPTION 'Test Database'
";
           cmd.ExecuteNonQuery();
                       
                       
           cmd.CommandText = @"
CREATE MODULE ""edbmigratedbisam2""
PATH 'C:\Program Files (x86)\ElevateDB 2 ADD\libs\edbmigratedbisam2unicode\edbmigratedbisam2.dll'
--DESCRIPTION 'DBISAM 2 Migrator Module (Unicode)'
";
           cmd.ExecuteNonQuery();

           connection.ChangeDatabase("MyDatabase");

           cmd.CommandText = @"
CREATE MIGRATOR ""DBISAM2ToElevate""
MODULE ""edbmigratedbisam2""
";
           cmd.ExecuteNonQuery();

cmd.CommandText = @"
MIGRATE DATABASE FROM ""DBISAM2ToElevate""
USING DatabaseDirectory = 'C:\Dbisam2Db' , TablePasswords='secret'
WITH DATA
";
           cmd.ExecuteNonQuery();
       }
   }
   finally
   {
       connection.Close();
   }
}

Hi!

Ok, for some reason today i can execute the first three statements (CREATE DATABASE, CREATE MODULE, CREATE MIGRATOR) without Index-out-of-bounds exception. I have no idea why. I do not have changed the code ...?!
On executing the CREATE MODULE statement i get an MDA exception (LoaderLock). Is this a problem?

Now i get an exception on executing the migration statement:

cmd.CommandText = @"
MIGRATE DATABASE FROM ""DBISAM2ToElevate""
USING DatabaseDirectory = 'C:\Dbisam2Db' , TablePasswords='secret'
WITH DATA
";

Error: "ElevateDB Error #401 The parameter DatabaseDirectory does not exist"

I can execute the MIGRATE statement in the ElevateDB Manager without any problems.
I have noticed, that the MigratorParams table is empty. Is this a problem?

Regards an thanks,
Jan

Jan,

<< Ok, for some reason today i can execute the first three statements
(CREATE DATABASE, CREATE MODULE, CREATE MIGRATOR) without
Index-out-of-bounds exception. I have no idea why. I do not have changed the
code ...?!
On executing the CREATE MODULE statement i get an MDA exception
(LoaderLock). Is this a problem? >>

Both of these issues are most likely due to issues with loading native DLLs
from an assembly in the Visual Studio IDE while debugging a managed
application:

http://msdn.microsoft.com/en-us/library/ms172219.aspx

http://russtaylor.co.uk/2009/11/loaderlock-was-detected-error-in-vs-2008/

<< Now i get an exception on executing the migration statement:

cmd.CommandText = @"
MIGRATE DATABASE FROM ""DBISAM2ToElevate""
USING DatabaseDirectory = 'C:\Dbisam2Db' , TablePasswords='secret'
WITH DATA
";

Error: "ElevateDB Error #401 The parameter DatabaseDirectory does not
exist" >>

That's because the module wasn't loaded properly, thus it can't find any
parameters for the module.

The solution is to turn off the MDA in the IDE, or don't run the managed
application under the debugger when dealing with native ElevateDB external
modules like the migrator modules.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi!

Update: I have just switched back the configuration from framework 4.0 to framework 2.0.
Now i can execute the MIGRATE statement at runtime, but i'm getting a #401 exception
with strange unicode charachters on migrating one of the tables (see attachment).

I can still successfully execute the MIRATE statement in ElevateDB Manager (Unicode).
I have the impression of doing something totally wrong, so I would appreciate a feedback.

Regards and thanks,
Jan

"Tim Young [Elevate Software]" wrote:

Jan,

<< ...
The solution is to turn off the MDA in the IDE, or don't run the managed
application under the debugger when dealing with native ElevateDB external
modules like the migrator modules. ...>>

I've already tried. This is the result:
framework 4: immediate exception "ElevateDB Error #401 The parameter DatabaseDirectory does not exist"
framework 2: migration starts and stops with strange exceptions

Regards and thanks,
Jan

Jan,

<< Update: I have just switched back the configuration from framework 4.0 to
framework 2.0.  Now i can execute the MIGRATE statement at runtime, but i'm
getting a #401 exception with strange unicode charachters on migrating one
of the tables (see attachment). >>

The framework is a coincidence - the problem is somewhere in the DBISAM 2
code that is causing a random memory overwrite and the ultimate issue with
DBISAM 2.  It's going to take some time to track this one down.

As for the DatabaseDirectory parameter issue - I cannot replicate this at
runtime, so it appears to still be a debug issue in the IDE.  Apparently,
turning off the MDA isn't enough since the Loader Lock problem still occurs.
It's either that or the same issue as above is causing issues with loading
the module at various times.

--
Tim Young
Elevate Software
www.elevatesoft.com

Jan,

Okay, here's what I've got so far:

1) Tried it with Delphi 2007 and DBISAM 2.x.  This fails with all sorts of
random errors in the strings.  The reason that we use Delphi 2007 is that it
is the latest version that supports WideStrings that also uses AnsiString as
the default string type, which DBISAM 2 requires since it hasn't been
updated in about 10 years, and most certainly has not been updated to
support Unicode as the default string type.

2) Tried it with Delphi 2009 and DBISAM 4.x.  This worked.

3) Tried it with Delphi 2007 and DBISAM 4.x, and this also fails in the same
way that the DBISAM 2.x migrator fails.  So, it appears that there's an
issue with Delphi 2007 and WideString usage.

I'm going to do some more playing with this, but it seems that I may have to
build in an "upgrade before migrate" option for the DBISAM 4.x migrator.  I
really am not in a position to port the DBISAM 2.x engine to Delphi 2009 or
higher with Unicode support, so that is really the only option.

--
Tim Young
Elevate Software
www.elevatesoft.com