Well, you might do some speed tests, to see if you really save time in the second phase (searching for an available record, and using or re-using it). The time for the first phase would presummably be done at times when few people, or no people, need the application - so the speed doesn't matter that much, in this case.

I think it is not worthwhile, and too complicated - but some people do need top performance, and this may be worth a try.

One possible complication is violation of rules, especially field rules, record rules, and candidate or primary indices. I think that if all the records added are deleted, that should reduce your problems. Candidate indices should have the filter: "not deleted()", in any case.

>In a different thread Mark Derail made a comment. Since it's not really germane to the original topic, I took my question to a new thread.
>

>Isn't the only 'bad' thing about DBF's is record addition, which can be compensated with
>creating millions of records ahead of time and doing record recycling?
>

>
>I'm looking for more detail on exactly what this means. For example
>

INSERT INTO table FROM MEMVAR

>should be avoided in favor of preloading a large number of empty records and then
>

>SELECT table
>LOCATE FOR available for adding
>GATHER MEMVAR MEMO (or some equivalent like GATHER NAME)
>

>
>All instruction gratefully appreciated............Rich