Hi,

tried to migrate DBISAM4 Database to EDB2 using EDB Manager and the non-unicode migrator
module. After some tables are done, I get :

ElevateDB Error #700: An error was found in the statement at line 1 and column 1 ...

Tried with and without data, and verified the dbisam tables. Don't have the time to
investigate further, but at first look it seems the trouble comes from tables that use the
RecordID Field as Primary Index.

Heiko


That used to work. Haven't tried it in 2.01 yet, but in my migration code I had to get rid of the RecordID field and the index created AFTER tables had been converted.

Roy Lambert [Team Elevate]

Heiko,

<< tried to migrate DBISAM4 Database to EDB2 using EDB Manager and the
non-unicode migrator module. After some tables are done, I get : >>

Could you send me the tables ?  We had some issues with the RecordID system
field a while ago in EDB1, but they were fixed, so it must be something
different that isn't readily apparent.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

you got mail

Tim,

after this beeing not adressed in 2.00 B2 I gave it a second look, and found out, that the
migrator module can't handle:

- ";" in an index name
- index name length greater than 40 characters
- fieldvalue null in a primary or unique index field. Solving that one won't be
easy...maybe add a new parameter to define how such a situation should be handled - set
the fields to emptystring or "0", delete the whole record, set the index to not unique, or
create a new primary index...

I wrote a little converter to get my db migrated, so don't hurry.

Heiko.

Heiko,

<< after this beeing not adressed in 2.00 B2 >>

Sorry, I completely missed this.  I'll see about getting the migrators
updated to replace any ';' in the index names with underscores.  Apart from
that, the other issues probably need to be addressed in the source data
before the migration.

<< - ";" in an index name >>

Covered already.

<< - index name length greater than 40 characters >>

Can't do anything about this one - the limit for identifiers is 40
characters.

<< - fieldvalue null in a primary or unique index field. Solving that one
won't be easy...maybe add a new parameter to define how such a situation
should be handled - set the fields to emptystring or "0", delete the whole
record, set the index to not unique, or create a new primary index... >>

Yes, this one is a tough one, and I think the best solution is to prep the
data before the migration.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>>Can't do anything about this one - the limit for identifiers is 40
characters.

Simply truncate the index name. Better it differs from the original one (does it anyway,
after the semicolon treatment) than to experience SQL errors during migration, which point
to nowhere.

>>Yes, this one is a tough one, and I think the best solution is to prep the
data before the migration.

A hint in the manual or a messagebox in EDBManager to ensure this would do, at least you
would encounter an "expected error" then.

Heiko



--
Tim Young
Elevate Software
www.elevatesoft.com

Heiko,

<< Simply truncate the index name. Better it differs from the original one
(does it anyway, after the semicolon treatment) than to experience SQL
errors during migration, which point to nowhere. >>

Sorry, yes, I understand that - I was referring to the fact that I can't
increase the length.  Sorry for not being more clear on this point.

<< A hint in the manual or a messagebox in EDBManager to ensure this would
do, at least you would encounter an "expected error" then. >>

I'll see what I can do.

--
Tim Young
Elevate Software
www.elevatesoft.com

Heiko,

I was going back through my email trying to find your email with the DBISAM
tables, and I can't find it, which is why I didn't address these issues in
EDB 2.00 B2.  However, I think the issue is that it might have accidentally
been deleted by me when I was clearing out some "out of office" replies from
when I sent out a mass emailing regarding 2.0.  Could you please send me
those tables again ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>>which is why I didn't address these issues in EDB 2.00 B2.  
No harm done.
>>Could you please send me those tables again ?
Will do.

BTW, you shouldn't be working on saturdays, unless -like me- it gives you an excuse for
not doing domestic work

Heiko