Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Migrating DBISAM2 - Error #700
Thu, May 19 2011 8:22 AMPermanent Link

Jan

Hi!

I get an error #700 if i try to migrate a DBISAM2 table to Elevate DB (Unicode) - this is the statement:

MIGRATE DATABASE FROM "DBISAM 2"
USING
"BlankNullStrings" = FALSE,
"Collation" = 'UNI',
"DatabaseDirectory" = 'C:\Temp',
"TablePasswords" = ''
WITH DATA

This is the error message:
ElevateDB Error #700 An error was found in the default column expression at line 1 and column 1 (Expected NULL expression but instead found 0)

The migration seems to stop at a special table (please see attached file).
Whats wrong with the table?

Regards and thanks,
Jan



Attachments: elevate.zip
Thu, May 19 2011 9:07 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Jan


I tried to take a look, and to do so had to upgrade to DBISAMV4 - the log tells me

Upgrade of table EngineReport to version 4.00 started at 19/05/2011 14:01:01...
Field definitions of EngineReport upgraded to latest table version 4.00...
3 records of EngineReport upgraded to latest table version 4.00...
Index definitions of EngineReport upgraded to latest table version 4.00...
BLOB header of EngineReport upgraded to latest table version 4.00...
10 BLOB blocks of EngineReport upgraded to latest table version 4.00...
Repair of table EngineReport started at 19/05/2011 14:01:01...
Invalid default value for field Intervals in table header, error fixed...
Invalid total record count of 0, error fixed...
Repair of table EngineReport completed at 19/05/2011 14:01:01...


So it looks as though there's a problem with the column. I didn't keep the utilities from that far back so I can't have a look before it was upgraded.

Intervals is a memo column and I'm surprised it had a default to start with. Try repairing the table (or altering by hand) before doing the conversion.


Roy Lambert [Team Elevate]
Thu, May 19 2011 10:14 AMPermanent Link

Jan

Roy

The table was created by code at runtime. Reparing with DBISAM 2 has no effect and altering with V2 System Utility does not work, because the default values for Memo fields are not supported (read only in GUI).
But we will find a solution.

Regards and thanks,
Jan
Thu, May 19 2011 11:37 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Jan

>The table was created by code at runtime. Reparing with DBISAM 2 has no effect and altering with V2 System Utility does not work, because the default values for Memo fields are not supported (read only in GUI).
>But we will find a solution.

Do you mean as part of the migration or sometime earlier? If as part of the migration there's something wrong with your code, if earlier and DBISAM V2 can read it then as part of your migration create a new table with the same structure (but without the problem default value) copy the data over to it, delete the problem table and rename the temporary table. Then get on with the transfer.

When I rewrote a major app I did a lot of the conversion of the tables using DBISAM because I knew what I was doing with it and then migrated them across and added indices and full text indexing. All done in one program and fairly effective.

Roy Lambert [Team Elevate]
Fri, May 20 2011 9:28 AMPermanent Link

Jan

Roy

I hope wie can alter the table before migration. Apparentlyit it's possible to define default values for memo fields if the table is created at runtime. So maybe we can remove the default value at runtime ...

Regards and thanks,
Jan
Image