Roy, it seems that might work. This would be the way to import from DBISAM databases, I suppose?

Lucian

Lucian

>Roy, it seems that might work. This would be the way to import from DBISAM databases, I suppose?

I seem to recall that for DBISAM import the migrators translate autoincs to generated by default anyway.

Roy Lambert [Team Elevate]

Roy,

<< Any chance of sneaking in times for statements like CREATE TABLE AS in
EDBManager when you sort this one out? >>

I'll have to double-check on this one.  I can't remember exactly what the
sticking point is with CREATE TABLE AS.

--
Tim Young
Elevate Software
www.elevatesoft.com

Lucian,

<< The thing is I am importing some DBISAM tables where RecRef is autoinc.
It is supposed to be autoinc also in EDB, however for the import, I create
the table(s) with RecRef INTEGER and only when I'm done with the import I am
restructuring the tables. What exactly am I supposed to do if I want to
obtain an autoinc column with a new lastautoinc value? From your answer I
understand I have to call twice ALTER TABLE, once to get an autoinc column
and second to reset the seed? If this is true, I understand it's a bug and
it will get fixed, right? >>

Yes, it is true, and no, it is not a bug, for the reasons that I've already
outlined.  The important thing to remember is:

Seed value in the catalog <> Next seed value in the table file

The first controls what seed value is used for the IDENTITY column when a
new table file is created on disk, and the second controls which value is
assigned next for the IDENTITY column.  In the case of a newly-created
table, the two are always the same.  For existing tables, the two can be
completely different.  For example, in your case you will want to use the
RESTART WITH clause to set the next IDENTITY column value for the existing
table files.  However, you *don't'* want EDB to create a new table file that
starts with a seed value that matches that value - you would want the
catalog to continue to have the seed value set to 0 for any newly-created
table files.

Do you see the difference ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>The first controls what seed value is used for the IDENTITY column when a
>new table file is created on disk, and the second controls which value is
>assigned next for the IDENTITY column. In the case of a newly-created
>table, the two are always the same. For existing tables, the two can be
>completely different. For example, in your case you will want to use the
>RESTART WITH clause to set the next IDENTITY column value for the existing
>table files. However, you *don't'* want EDB to create a new table file that
>starts with a seed value that matches that value - you would want the
>catalog to continue to have the seed value set to 0 for any newly-created
>table files.
>
>Do you see the difference ?

I don't know about Lucian but you've baffled me. The only instance I can think of where EDB would create the same table without a separate CREATE when you give it any start value you like is when a moron like me zaps then via Explorer.

Roy Lambert

Roy,

<< I don't know about Lucian but you've baffled me. The only instance I can
think of where EDB would create the same table without a separate CREATE
when you give it any start value you like is when a moron like me zaps then
via Explorer. >>

Yes, and morons like me and many others, also.  This is a behavior that is
useful to have, and changing the way that the IDENTITY column seed values
work would break this behavior.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< I don't know about Lucian but you've baffled me. The only instance I can
>think of where EDB would create the same table without a separate CREATE
>when you give it any start value you like is when a moron like me zaps then
>via Explorer. >>
>
>Yes, and morons like me and many others, also.

Surely you don't delete table files at the OS level, surely you always use DELETE FROM ....

Roy Lambert

Roy,

<< Surely you don't delete table files at the OS level, surely you always
use DELETE FROM .... >>

Yeah....sure.....

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< Surely you don't delete table files at the OS level, surely you always
>use DELETE FROM .... >>
>
>Yeah....sure.....

I'm so glad about that. For a moment I thought I might have to search out the post where some experienced database engine developer issued a health warning about using Windows to do the equivalent of a DBISAM.EmptyTable <vbg>

Roy Lambert [Team Elevate]

Roy,

<< I'm so glad about that. For a moment I thought I might have to search out
the post where some experienced database engine developer issued a health
warning about using Windows to do the equivalent of a DBISAM.EmptyTable
<vbg> >>

Good practices vs. what we actually do in practice are two different things.


--
Tim Young
Elevate Software
www.elevatesoft.com