Tim -

I found a little problem with the NexusDB migrator.

It makes the assumption that the "default index" for a Nexus table is a primary key, and assumes it to be unique, even if it was not defined as such...


Curt

Curt,

<< I found a little problem with the NexusDB migrator.

It makes the assumption that the "default index" for a Nexus table is a
primary key, and assumes it to be unique, even if it was not defined as
such... >>

For the migrator to think that any index is a primary or unique key, the
ixPrimary or ixUnique attributes must be set by the source database for a
particular TIndexDef index definition.  The only thing I can think of is
that NexusDB must be setting these flags.

If you want to send me your NexusDB database, I can tell you for sure
whether this is the case or not.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim -

I'd be glad to, but I already altered the NexusDB structural definition so I could complete my migration...

However, I _assure_ you that it was translating non-unique Nexus indices to unique EDB indices, and then aborting the migration because of key violations....   


Curt

Curt,

<< However, I _assure_ you that it was translating non-unique Nexus indices
to unique EDB indices, and then aborting the migration because of key
violations....   >>

I'll check this out along with the case-sensitivity issue and make sure that
it is corrected for the next build.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim -

Another nice feature might be to allow the migrator to complete, even if there are some conversion issues.   When I was doing my migration, I had to re-do it maybe 40 times, because I'd get to an error, correct it, get to the next error, correct that, etc.   By the time I got through all the issues, I had done a LOT of redundant migration.    If it had been allowed to run to completion, I could have gotten a comprehensive list of errors from the log, fixed them, and re-run the migration once.

Curt

Curt,

<< Another nice feature might be to allow the migrator to complete, even if
there are some conversion issues.   When I was doing my migration, I had to
re-do it maybe 40 times, because I'd get to an error, correct it, get to the
next error, correct that, etc.   By the time I got through all the issues, I
had done a LOT of redundant migration.    If it had been allowed to run to
completion, I could have gotten a comprehensive list of errors from the log,
fixed them, and re-run the migration once. >>

The problem is the issue of cascading failures, especially if certain tables
are not migrated successfully.  However, I'll see what I can do about having
it log the errors instead.

--
Tim Young
Elevate Software
www.elevatesoft.com

Curt,

<< However, I _assure_ you that it was translating non-unique Nexus indices
to unique EDB indices, and then aborting the migration because of key
violations....   >>

I cannot reproduce this here.   Can you possible give me a CREATE TABLE
statement for NexusDB that defines a table that will cause such an error ?
Is it only a table with a single index defined on it ?

I've tried migrations with tables containing primary keys, and tables with
normal indexes, and both work fine.

--
Tim Young
Elevate Software
www.elevatesoft.com