Hi,
Another way to do it may be this, preallocate the file with deleted records with the PK set with an Autoinc Integer, then when a new record is required just recall it and populate the fields.
Advantages are that the EOF marker doesn't change unless the preallocation set point kicks in, this can be done automatically or as part of a maintenace routine

SET PATH TO Your Database

OPEN DATABASE Your.DBC

USE Your!YourTable.dbf
* Check that preallocation is greater than 1% of file
COUNT FOR DELETED() TO lnTotDeleted
lnTotRecs=RECCOUNT()
IF lnTotDeleted < (lnTotRecs-lnTotDeleted)/100
	lnNoRec2Add = CEILING((lnTotRecs-lnTotDeleted)/100)
	FOR x = 1 TO lnNoRec2Add
		APPEND BLANK 
		DELETE 
	ENDFOR 
ENDIF 

* Looks for deleted record in the table
LOCATE FOR DELETED()

IF FOUND()
	* bring it back to life and blank its fields
	RECALL

>>>>>>AutoInc clashes with Table buffering applied on parent table. One may rethink interface to avoid these cases.
>>>>>
>>>>>The only other way (besides the kludge approach I already thought off) I see is to not allow to enter children unless we saved the parent.
>>>>
>>>>I think you exaggerate. Frankly, I never get in this situation (generally speaking I don't use Tableupdate, except special cases), but why do you need to have table buffering on parent? You could have row buffering and go by each record, saving parent record, getting Id, and then saving child records.
>>>
>>>I always give a choice to revert all the changes made and I always use table buffering.
>>
>>This can be done without table buffering :). This whole thing (buffering) appeared as a way to simplify code many years ago. At that time people knew how to do it without buffering, many people who started it after may believe that it just not possible.
>>Btw, if you mean reverting on Save point, then it's done by Transaction, not by buffering.
>
>I do not see a need for a transaction in a case of a single table updating. If we update multiple tables, then we do need to use transactions.
>
>I took a closer look into the simple framework I adapted here and it looks like it was designed only to handle single table updates in row-buffered mode. I'm working on some changes to that as we speak.