AutoInc problem, VFP8

Just wondering if anyone else has come across this problem, it's the first
time I've seen it.

One of my tables has a pk, inst_id, which is set to autoinc. I bombed today
on the uniqueness of my key which seemed strange considering I have no
reason to manipulate any autoinc'd pk's directly. Nevertheless, it did turn
out that the next val somehow or other had become set to a ridiculously low
value ( 3 in a table of 50 entries). I have not experienced any data
corruptions; and I always open my dbc's with the validate clause.

Anders
Sat Mar 19 07:12:12 CST 2005

VFP9 has a function GETAUTOINVALUE( ) that could be added to the
pre-validation.
You will have to recreate the index with then ALTER TABLE x ALTER COLUMN y
command.
I have no clue how the table header gor corrupted.
-Anders

"Lew" <lew@clsystems.com> wrote in message
news:#Jprgo$KFHA.1156@TK2MSFTNGP09.phx.gbl...
> Just wondering if anyone else has come across this problem, it's the first
> time I've seen it.
>
> One of my tables has a pk, inst_id, which is set to autoinc. I bombed
today
> on the uniqueness of my key which seemed strange considering I have no
> reason to manipulate any autoinc'd pk's directly. Nevertheless, it did
turn
> out that the next val somehow or other had become set to a ridiculously
low
> value ( 3 in a table of 50 entries). I have not experienced any data
> corruptions; and I always open my dbc's with the validate clause.
>
>

trw7at
Mon Mar 21 10:44:03 CST 2005

Lew seemed to utter in news:#Jprgo$KFHA.1156@TK2MSFTNGP09.phx.gbl:

> Just wondering if anyone else has come across this problem, it's the
> first time I've seen it.
>
> One of my tables has a pk, inst_id, which is set to autoinc. I bombed
> today on the uniqueness of my key which seemed strange considering I
> have no reason to manipulate any autoinc'd pk's directly. Nevertheless,
> it did turn out that the next val somehow or other had become set to a
> ridiculously low value ( 3 in a table of 50 entries). I have not
> experienced any data corruptions; and I always open my dbc's with the
> validate clause.

The VFP-supplied auto-incrementing fields have a number of
sticky issues. For those reasons, I continue to use my own
auto-incrementing logic. It never creates duplicate keys, is
simple, fast, and avoids the oddities of VFP's autoinc fields.

-- TRW
_______________________________________
t r w 7
at
i x dot n e t c o m dot c o m
_______________________________________

Lew
Mon Mar 21 18:33:21 CST 2005

Could you please describe these issues and what problems you've actually
encountered?
Thanks.
-Lew
"Tim Witort" <trw7at@ixdot.netcomdotcom> wrote in message
news:Xns96205958196A0timwitortwrotethis@207.217.125.201...
> Lew seemed to utter in news:#Jprgo$KFHA.1156@TK2MSFTNGP09.phx.gbl:
>
>> Just wondering if anyone else has come across this problem, it's the
>> first time I've seen it.
>>
>> One of my tables has a pk, inst_id, which is set to autoinc. I bombed
>> today on the uniqueness of my key which seemed strange considering I
>> have no reason to manipulate any autoinc'd pk's directly. Nevertheless,
>> it did turn out that the next val somehow or other had become set to a
>> ridiculously low value ( 3 in a table of 50 entries). I have not
>> experienced any data corruptions; and I always open my dbc's with the
>> validate clause.
>
> The VFP-supplied auto-incrementing fields have a number of
> sticky issues. For those reasons, I continue to use my own
> auto-incrementing logic. It never creates duplicate keys, is
> simple, fast, and avoids the oddities of VFP's autoinc fields.
>
> -- TRW
> _______________________________________
> t r w 7
> at
> i x dot n e t c o m dot c o m
> _______________________________________

trw7at
Tue Mar 22 12:26:48 CST 2005

Lew seemed to utter in news:#sqOObnLFHA.2420@TK2MSFTNGP12.phx.gbl:

> Could you please describe these issues and what problems you've actually
> encountered?
> Thanks.
> -Lew

*I* haven't encountered the problems because I never use the autoinc
fields. The issues, however, have been well documented by many other
developers in this group and I've listened to speakers at the DevCons
discuss the autoinc problems. I've never heard one of them recommend
the autoinc fields over a simple, reliable home-grown autoinc field
process.

Some issues include how they behave when views are used,
backward compatibility concerns, and others.

You can find plenty of details by going to google groups and searching
in the fox groups for "autoinc". You'll find about 100 threads about
using autoinc fields - most of which are dealing with the shortcomings.

-- TRW
_______________________________________
t r w 7
at
i x dot n e t c o m dot c o m
_______________________________________

PabloSr
Tue Mar 22 19:03:01 CST 2005

Tim, at risk of introducing some redundancy, please tell me, do these
limitations and shortcomings remain in Visual FoxPro Version 9?

--
Best regards.

PabloSr.
Still Learning!
That which I value most!
==================

: Some issues include how they behave when views are used,
: backward compatibility concerns, and others.
:
: You can find plenty of details by going to google groups and searching
: in the fox groups for "autoinc". You'll find about 100 threads about
: using autoinc fields - most of which are dealing with the shortcomings.

trw7at
Wed Mar 23 11:08:10 CST 2005

PabloSr seemed to utter in news:#$oxQQ0LFHA.1096@tk2msftngp13.phx.gbl:

> Tim, at risk of introducing some redundancy, please tell me, do these
> limitations and shortcomings remain in Visual FoxPro Version 9?
>

I haven't heard one way or the other about that. Since I basically
committed myself to using my own autoincrement routine, I haven't
followed the improvements, if any, to VFPs autoincrementing.

-- TRW
_______________________________________
t r w 7
at
i x dot n e t c o m dot c o m
_______________________________________