Hi Tim,

The AUTOINC is a little different in ElevateDB than it was in DBISAM. I have
some questions about this.

What is the difference between the following 2 options:

ALWAYS AS IDENTITY (START WITH <SeedValue>, INCREMENT BY <IncrementValue>)|
BY DEFAULT AS IDENTITY (START WITH <SeedValue>, INCREMENT BY
<IncrementValue>)

They seem to be doing the exact same thing to me, but as there are 2 options
there must be something different though. Can you explain what this is? If I
had to guess, the point of when the value is determined is different.

Where does ElevateDB stores (saves) this information? In the Catalog file?
If yes, does this not add an extra risk as it is better to write to this
part of ElevateDB as little as possible. Here is a quote from you in the
"Corrupt catalog file" thread:

"An improper shutdown would do it after any changes to the catalog.
However,
updates to the catalog should be rather infrequent at most.  Is that not the
case with your application ?"

If not, is it generated (computed) by executing a SELECT MAX statement of
some sort?

Thanks in advance.

Best regards and Merry Christmas to you and your family, as well as to all
readers of this newsgroup.

Fons

P.S. It is still 24 december and about 9:30 hours (in the morning) where I
live. BTW, we celibrate Christmas on 25 december, where others do so at 24
december in the evening.

Fons,

<< What is the difference between the following 2 options:

ALWAYS AS IDENTITY (START WITH <SeedValue>, INCREMENT BY <IncrementValue>)|
BY DEFAULT AS IDENTITY (START WITH <SeedValue>, INCREMENT BY
<IncrementValue>) >>

ALWAYS will always increment the identity column and replace it's value on
INSERT, regardless of the data already present in the column.  BY DEFAULT
will only populate the identity column if the column value is NULL on
INSERT.

<< Where does ElevateDB stores (saves) this information? In the Catalog
file? >>

It stored the last number used in the table file (.edbtbl).

<< Best regards and Merry Christmas to you and your family, as well as to
all  readers of this newsgroup. >>

Thanks very much.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> ALWAYS will always increment the identity column and replace it's value on
> INSERT, regardless of the data already present in the column.  BY DEFAULT
> will only populate the identity column if the column value is NULL on
> INSERT.

While reading this, it is quite clear, so I should have figured it out by
myself  

> It stored the last number used in the table file (.edbtbl).

Is this value in any way accessible and perhaps even editable?

Thanks.

Best regards,
Fons

Fons,

<< Is this value in any way accessible and perhaps even editable? >>

Not yet.  I've got to provide the ability via the ALTER TABLE statement to
reset/modify the seed value.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> Not yet.  I've got to provide the ability via the ALTER TABLE statement to
> reset/modify the seed value.

On the list for version 1.08..?

And using a C/S setup, what is the chance that this value get corrupted and
messes up the R.I. ?   I am always somewhat cautious when using an autoinc
mechanism. I know DBISAM has a good reputation on this subject, but, let's
just say I need to be reassured.

Thanks.

Best regards,
Fons

Fons,

<< On the list for version 1.08..? >>

Yes, along with some new SQL/PSM functions and at least one really major new
feature.

<< And using a C/S setup, what is the chance that this value get corrupted
and messes up the R.I. ?   I am always somewhat cautious when using an
autoinc mechanism. I know DBISAM has a good reputation on this subject, but,
let's just say I need to be reassured. >>

With EDB it is highly unlikely that the identity seed values are corrupted
in general.  EDB has "write tracking" in it, so that if a write to any table
is interrupted between the time the write is initiated and completed, then
EDB will prevent any further reads of the table without issuing an
exception:

'A write operation did not complete and a repair is required'

It's not 100% foolproof, but it does eliminate a lot of possible issues.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Thanks for the added (backgound) info. Informative and reassuring

Best regards,
Fons