Charlie,

>> Are you telling me that you don't have your copy procedures down pat and
>> that you don't even test the tables you've copied?
> That's what I'm telling you.

You should consider writing a cheat sheet. I use a number of them to list
all the steps I need to take for the successful completion of a task.
It's not a question of intelligence; some tasks are repetive and boring and
I would not pay as much attention to them if I didn't have to put
checkmarks in my cheat sheets.


>> Furthermore, are you telling that your custom AutoIncrement procedure
>> doesn't handle this "problem"? Maybe it's time to refactor it...
> I'm all ears. If there's a key in the table that's larger than the value
> in the Keys.DBF, what would you do to check for that? SELECT MAX(Primary
> key)? Or perhaps you watch for the error and then update the stale key?
> Other thoughts?

My function reads the number of records and the distribution of thee PK
values before determining whether it should attempt to generate a
key that is smaller/larger than any value in the table, or whether to
attempt to fill a hole. The heuristic is based on real-time statistical
analysis of the data. Note that the analysis code segment of the heuristic
doesn't kick in unless the key generated is a duplicate of an existing PK.

I do not update stale keys but I don't see why it would not be possible to
do so.


> Based on the way you work and your typical projects you may not care for
> auto-incrementing keys in the data engine. I'm surprised, but I'll get
> over it. My opinion, (and I'll have to ask my friends theirs) is that is a
> very helpful feature indeed.

As I said before, we don't.

Daniel