Ronald,

<< there is only one error left, I can't get rid of:

#401: The parameter DatabaseDirectory does not exist >>

Does the DatabaseDirectory parameter show up if you try to interactively try
to migrate a database using the ElevateDB Manager ?   The parameters are
retrieved from the .dll itself, so if you're using the correct migrator
module, it should be there and assignable.

You can also just query the MigratorParams table in the Configuration
database to find out which parameters are valid for which migrator:

http://www.elevatesoft.com/edb1sql_migratorparams_table.htm

The DatabaseDirectory parameter should show up in there for the DBISAM4
migrator that you have created.

--
Tim Young
Elevate Software
www.elevatesoft.com

Ronald,

<< You're right, it's error code 1011. Sorry about that...
The database directory is called
Z:\Repond\Repond 7\Test elevateDB\data Repond7
it is empty, except for the edbmigratedbisam4.dll... >>

That directory value should be fine.   There is no length limit for the
parameter value, so length should not be an issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

That's nice, but the error persists.
As I wrote earlier, it's all a bit confusing....
I've not been using much SQL in the previous years, but I have developed
and converted lots of fine programs with dbIsam 2.x/3.x/4.x. And now I
can't even convert a simple set of tables and I'm getting frustrated...
I posted the complete code for converting a dbIsam4 set to Roy, who has
given me a fine startingpoint. Hopefully he or you can tell me what's
wrong. When it works I will go back to the manual and do all the steps
again, to get the dbmanager to work.


Tim Young [Elevate Software] wrote:
> Ronald,
>
> << You're right, it's error code 1011. Sorry about that...
>  The database directory is called
>  Z:\Repond\Repond 7\Test elevateDB\data Repond7
>  it is empty, except for the edbmigratedbisam4.dll... >>
>
> That directory value should be fine.   There is no length limit for the
> parameter value, so length should not be an issue.
>

Ronald


Since you've essentially copied my code it should work - it does here, a test run has just completed.

I think the problem comes from the fact that I copy my data into the directory the new ElevateDB database is going to exist in, and that's confused you.

If I'm reading your code correctly

 Path :='c:\elevatedb\'; <<<<<<<< new ElevateDB database
 cDBisamPath :='c:\db\'; <<<<<<< old DBISAM database

then
      Execute('CREATE DATABASE ' + 'TEST' + ' PATH ' + QuotedStr(cDbIsamPath));
should be
      Execute('CREATE DATABASE ' + 'TEST' + ' PATH ' +QuotedStr(Path));


Roy Lambert

Ronald,

<< I've not been using much SQL in the previous years, but I have developed
and converted lots of fine programs with dbIsam 2.x/3.x/4.x. And now I can't
even convert a simple set of tables and I'm getting frustrated... >>

Yes, but you need to step back a bit and start with the basics.  In my
opinion, trying to do the migration right off the bat in your code has
confused the issue for you.

What I need for you to try is getting the migration working in the EDB
Manager.  Then we can move on to getting the migration to work in your code.

http://www.elevatesoft.com/edb1d7_migrating_dbisam_database_mgr.htm

I've tried every combination of long database directory names, etc. here and
I cannot get the migration to fail.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

I feel like a moron.....
It does not work.
Can you tell me what TfRLive is? It sounds like a component, but I trust
it contains a path?
As I understand you have everything in one directory, dbIsam tables,
Elevate tables and config stuff?

Thanks for your patience... I feel like a complete idiot.

Ronald

Roy Lambert wrote:
> Ronald
>
>
> Since you've essentially copied my code it should work - it does here, a test run has just completed.
>
> I think the problem comes from the fact that I copy my data into the directory the new ElevateDB database is going to exist in, and that's confused you.
>
> If I'm reading your code correctly
>
>   Path :='c:\elevatedb\'; <<<<<<<< new ElevateDB database
>   cDBisamPath :='c:\db\'; <<<<<<< old DBISAM database
>
> then
>        Execute('CREATE DATABASE ' + 'TEST' + ' PATH ' + QuotedStr(cDbIsamPath));
> should be
>        Execute('CREATE DATABASE ' + 'TEST' + ' PATH ' +QuotedStr(Path));
>
>
> Roy Lambert
>

I'm going to do that Tim.
As I understand from the things Roy Lambert has told me, there is some
sort of central system where one creates things, that don't have to be
created after that first time anymore. I think it's better if I try it
from the beginning one step at a time.

Thanks.

Tim Young [Elevate Software] wrote:
> Ronald,
>
> << I've not been using much SQL in the previous years, but I have developed
> and converted lots of fine programs with dbIsam 2.x/3.x/4.x. And now I can't
> even convert a simple set of tables and I'm getting frustrated... >>
>
> Yes, but you need to step back a bit and start with the basics.  In my
> opinion, trying to do the migration right off the bat in your code has
> confused the issue for you.
>
> What I need for you to try is getting the migration working in the EDB
> Manager.  Then we can move on to getting the migration to work in your code.
>
> http://www.elevatesoft.com/edb1d7_migrating_dbisam_database_mgr.htm
>
> I've tried every combination of long database directory names, etc. here and
> I cannot get the migration to fail.
>

Ronald

>I feel like a moron.....

Don't worry - you should have heard some of the things I would have suggested to Tim if he'd been stood in front of me when I started with it

>It does not work.
>Can you tell me what TfRLive is? It sounds like a component, but I trust
>it contains a path?

TfRLive is simply the path to the tables, in this case both DBISAM and ElevateDB

>As I understand you have everything in one directory, dbIsam tables,
>Elevate tables and config stuff?

No tables are in the directory E:\HH Dev\TfR\NLH\Live, the config stuff and dlls needed are in E:\HH Dev\Patches and when this goes live this one will be cleaned up and removed

>Thanks for your patience... I feel like a complete idiot.

Nah - there are some major conceptual changes between DBISAM and ElevateDB its not like the switch from Paradox/BDE to DBISAM - that one was EASY!

In your case I'd have three directories

1. old DBISAM tables
2. new shiny bright ElevateDB tables
3. application code & config directory

I'll let you decide what to put in 1 2 will take care of itself 3 will contain your code and the migrator dll.

EMail me the .pas and .dfm you're using and I'll get it working here.

Roy Lambert

Ronald,

<< I'm going to do that Tim. As I understand from the things Roy Lambert has
told me, there is some sort of central system where one creates things, that
don't have to be created after that first time anymore. I think it's better
if I try it
from the beginning one step at a time. >>

Yes, that's the configuration file.  It's called EDBConfig.EDBCfg by
default, and resides in the location specified by the configuration file
path.  The contents of the configuration file are represented in EDB by the
special system database called 'Configuration':

http://www.elevatesoft.com/edb1sql_configuration_database.htm

Once you create any object in the configuration database using DDL
statements such as CREATE USER, CREATE DATABASE, CREATE MIGRATOR, etc., the
object definition is stored in the configuration file permanently and does
not need to be defined again unless it is dropped or the configuration file
is erased, etc.

In addition, there are some "virtual" objects in the Configuration database
also, such as the DataTypes, Modules, ServerSessions, etc.  These objects
don't actually get stored in the configuration file, but rather exist in
some external form.  In the case of modules, they simply exist as a .DLL in
the configuration file path.  In the case of backups, they exist in the
directory specified by the SET BACKUPS PATH statement, or the configuration
file path if the backups path has not been explicitly set.

For each database, the table files are pretty much the same as with DBISAM.
However, there is one additional file for the database catalog called
EDBDatabase.EDBCat that is also present.  This is where all of the metadata
about the database is stored, such as the tables, views, procedures, etc.
along with their columns and other properties.  The table files themselves
only store the data, and do not contain any metadata information at all.
This is in contrast to DBISAM, which stored the table metadata inside of the
table files themselves.

Those are the basic fundamental differences between EDB and DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thank you, Tim.
Very clear. I think it will be easier now to answer questions when
starting the databasemanager.
I guess it's logical to keep different configuration files for the
unicode and non-unicode versions? I think that's also something that has
gotten mixed up here.
If i want to start all over again, is it enough to simply erase the
different config files, or are there also registry keys involved?

Tim Young [Elevate Software] wrote:
> Ronald,
>
> << I'm going to do that Tim. As I understand from the things Roy Lambert has
> told me, there is some sort of central system where one creates things, that
> don't have to be created after that first time anymore. I think it's better
> if I try it
> from the beginning one step at a time. >>
>
> Yes, that's the configuration file.  It's called EDBConfig.EDBCfg by
> default, and resides in the location specified by the configuration file
> path.  The contents of the configuration file are represented in EDB by the
> special system database called 'Configuration':
>
> http://www.elevatesoft.com/edb1sql_configuration_database.htm
>
> Once you create any object in the configuration database using DDL
> statements such as CREATE USER, CREATE DATABASE, CREATE MIGRATOR, etc., the
> object definition is stored in the configuration file permanently and does
> not need to be defined again unless it is dropped or the configuration file
> is erased, etc.
>
> In addition, there are some "virtual" objects in the Configuration database
> also, such as the DataTypes, Modules, ServerSessions, etc.  These objects
> don't actually get stored in the configuration file, but rather exist in
> some external form.  In the case of modules, they simply exist as a .DLL in
> the configuration file path.  In the case of backups, they exist in the
> directory specified by the SET BACKUPS PATH statement, or the configuration
> file path if the backups path has not been explicitly set.
>
> For each database, the table files are pretty much the same as with DBISAM.
> However, there is one additional file for the database catalog called
> EDBDatabase.EDBCat that is also present.  This is where all of the metadata
> about the database is stored, such as the tables, views, procedures, etc.
> along with their columns and other properties.  The table files themselves
> only store the data, and do not contain any metadata information at all.
> This is in contrast to DBISAM, which stored the table metadata inside of the
> table files themselves.
>
> Those are the basic fundamental differences between EDB and DBISAM.
>