Hi
I am using for the first time the type autoinc to create a primary key of an
archive.
The content is reliable? There are operations that can damage the contents
and make the connection shaft between two master-detail records?

Thanks

Carlos

"Carlos" <carlos@noemail.com> ha scritto nel messaggio
news:BB8A17A4-B2B2-4498-8405-3D6F54108C5F@news.elevatesoft.com...
> Hi
> I am using for the first time the type autoinc to create a primary key of
> an archive.
> The content is reliable? There are operations that can damage the contents
> and make the connection shaft between two master-detail records?
>
> Thanks
>
> Carlos

Sorry the mistake...

The content is reliable? There are operations that can damage the contents
and renumbered the value?

Carlos

Carlos


Autoincs in DBISAM are pretty good but they are not (in the earlier version you have) 100% reliable - probably around 99.5%. If you search these ngs you'll find that people can have problems.

The main complaint is that something happens and the next autoinc which you were expecting to be 1476 is 76509813 or something like that.

I would also say that I, and many others, have never had a problem with them.

Roy Lambert [Team Elevate]

Roy

>
> The main complaint is that something happens and the next autoinc which
you were expecting to be 1476 is 76509813 or something like that.
>
> I would also say that I, and many others, have never had a problem with
them.

I have used auitoincs extensively for many years.  My experience is that
pretty much all autoinc corruption has been a function of a table with dodgy
data being repaired.  FAT32 systems seemed to preallocate space for files
and if you had an unexpected power down you would get junk data at the end
of the file.  Running a repair would then set the autoinc to the highest
junk number.  As long as the garbage is cleared out and the autoinc reset I
don't have any problems.   This problem does not seem to occur with NTFS.


John

Roy,

<< Autoincs in DBISAM are pretty good but they are not (in the earlier
version you have) 100% reliable - probably around 99.5%. If you search these
ngs you'll find that people can have problems. >>

Please don't give the wrong impression here.  The only way that they aren't
reliable is if the table becomes damanged due to physical corruption, and
you then run a repair on the table.  In such a case, it is possible (not
probable) for the next autoinc value to be set to a very high number, but
only because there is junk in portions of the table's .dat file.  The
solution is to reset the next autoinc value using AlterTable, and remove the
junk records from the table using Delete.  All of this can be done fairly
quickly in the DBSYS utility:

1) Repair
2) Check the last autoinc value for the table
3) If it is very high, alter the table and reset it
4) Check the table for damaged data in the records, and remove any records
that contain nothing but junk

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Please don't give the wrong impression here.

I'm trying to give what I regard as an honest answer. My memory is a number of posts in V3 days regarding this issue with far less in V4 days.

Roy Lambert

"Roy Lambert" <roy.lambert@skynet.co.uk> ha scritto nel messaggio
news:3DA28F8A-F789-4324-90DE-DE43F44A79AE@news.elevatesoft.com...
> Tim
>
>
>>Please don't give the wrong impression here.
>
> I'm trying to give what I regard as an honest answer. My memory is a
> number of posts in V3 days regarding this issue with far less in V4 days.
>
> Roy Lambert


thanks for the suggestions, have been useful !

Carlos

Roy,

<< I'm trying to give what I regard as an honest answer. My memory is a
number of posts in V3 days regarding this issue with far less in V4 days. >>

I understand.    However, the wording was such that it gave the impression
that there was the possibility of an autoinc not working for unknown
reasons, and this is what I wanted to clarify.

--
Tim Young
Elevate Software
www.elevatesoft.com