Tim

I think we have missunderstand us a little bit. You should not scan the
complete table, this makes no sense to me. You should simply check the field
and key definitions to see if any fields of the PK in DBISAM is declaread as
"NOT NULL". If not all PK fields have "NOT NULL" (required option), the
migrator should generate a UNIQUE KEY instead a PRIMARY KEY. That's all.

Regards
Rolf

"Tim Young [Elevate Software]"  schrieb im Newsbeitrag
news:143565F4-3BD4-4E9A-8477-7855BF15F194@news.elevatesoft.com...

Rolf,

<< There are string and not string fields. "BlankNullStrings" will not help
at all, as this will break existing code, where it is important, that this
fields are NULL. So I think it would be the correct way to change the
migrator to produce UNIQUE KEY instead PRIMARY KEY in this sitation where
null fields are part of the primary key. Also if I'm not be able to use EDB
2 at all.  >>

I'll have to think about this some more.  I'm not sure how feasible it is to
scan entire incoming tables for NULL values, especially if those sources are
not DBISAM or other sources that I know for a fact can handle such scans
quickly.  Such a scan *must* be done prior to the creation of *any* of the
target tables, because it possibly affects the DDL for all tables (FKs).

--
Tim Young
Elevate Software
www.elevatesoft.com

Rolf,

<< I think we have missunderstand us a little bit. You should not scan the
complete table, this makes no sense to me. You should simply check the field
and key definitions to see if any fields of the PK in DBISAM is declaread as
"NOT NULL". If not all PK fields have "NOT NULL" (required option), the
migrator should generate a UNIQUE KEY instead a PRIMARY KEY. That's all. >>

That's going to break a *lot* of databases, so it's going to have to be a
new parameter for the migrator.  There are a lot of databases that don't
have NOT NULL for the primary key columns, that still have all primary key
columns populated in the actual rows coming over.

--
Tim Young
Elevate Software
www.elevatesoft.com