As far as I can remember (a couple of years since I last used Paradox tables)
Paradox remembers the last AutoInc value.
I once had a table problem similar to this - I ended up with one "Blank" Record
in the table - caused all sorts of problems...
I ended up having to Restructure as Integer (instead of AutoInc), Delete the
offending record, Save, Pack, etc. and then Restructure back as an AutoInc
Field.
Regards
Paul McKenzie
=========================
Paul McKenzie
Jetbet II Developer
=========================
[EMAIL PROTECTED]
Ph: (04) 576-6822
T.A.B. National Office
106-110 Jackson Street
Petone
New Zealand
____________________Reply Separator____________________
Subject: Re: [DUG]: Key Violation
Author: [EMAIL PROTECTED]
Date: 17/07/2001 13:53
Craig replied
>
> Hard to say, but I guess the first place to look would be the autoinc
> field. Though I use these as the single primary key in C/S databases,
> I've generally avoided them in Paradox tables. No compelling reason,
> just that they cause a lot of stress when things go bad. In your case,
> you could perhaps have used a DateTime stamp etc, which would have also
> been informative to the users.
Now that's a good idea
>
> How were the "bulk deletes" done? Was there a problem there?
These were done programmatically through an archiving program supplied by
me. May be more likely cause was a system crash last week.
> Can you view the table ok? Any autoinc fields look screwy?
Can view the table OK and all looks to be fine.
> Does Restructuring help? Perhaps after deleting the index (.PX?)
By this, do you mean to Pack the table (in DBD) after deleting the index?
Is there any difference between using the DBD / Erase index and merely
deleting the .PX file? I will try this.
> Can you work out what the next autoinc number is, and confirm whether or
> not the next insert is going to bomb? This may point to an existing
> record which you may be able to toss.
No - can't see any obvious bomb condition. Don't know how Paradox figures
the next number. I guess it just adds 1 to the max value of that column -
which is all that I can look for too - so no possibility of a conflict
between me and Paradox!
If there is no clear 'gimmie' fix for this I might have to attack it from
a
different angle.
Have just figured that there is only one place in my app that needs the
table ordered this way and think I might change things to use a TQuery with
an Order by clause. It's not speed critical.
>
> Sorry I can't be of more help.
>
> Craig.
Thanks for your input
Mark
>
> Mark Howard wrote:
>
> > Hi I have a Paradox table with a composite primary key made up
> > of:DocketNo IntegerDocketCheck Char(1)DocInd AutoIncr I have
> > also defined a secondary index on DocInd (EntryOrder), which is used
> > whenever I want to order the table in the order of entry. The client
> > site has recently done some bulk deleting from this table and now
> > cannot post to the table, getting error"Key Violation: Index -
> > EntryOrder" I have tried deleting the index files and recreating them,
> > but to no effect. Can anyone throw any light on this or suggest any
> > remedies. Thanks Mark
>
>
--------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
> Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
>
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/(See
attached file: att1.eml)
att1.eml
