George,

>>

>>APPEND BLANK IN MyTable
>>TABLEUPDATE(2,.T.,"MyTable")
>>? MyTable.Pk
>>

>You'd be better served use INSERT INTO.

Nope, The INSERT SQL command contains a bug when dealing with default values. APPEND BLANK is better in cases when wanting to work default values.

>>Come one george, I know that. This is not the issue. In many of my projects forms I use a record buffered table for the parent and several table buffered local views for entering the childs.
>>
>>In these forms, I could add a parent and childs, without commiting (tableupdate) any data so that I can undo the add anytime. Since all data still is buffered, how am I ever going to relate the parent and child without knowing the PK value of the parent ? I simply can't do this with an autoincrementing feature on the table. I need them on my views and rowbuffered data also.

>You don't know this.

What don't I know? Looking at the technical problem it is very unlikely that I could use the incrementing key feature on SQL views, or on buffered data. None of the DBMS I know are supporting autoincrementing keys on non committed data.

>>>If you need the keys to be meaningful, sure. But as I've said, surrogate PKs aren't.
>>
>>You need to know what the PK value is whenever you want to commit both inserted parent and child data in one transaction.

>Nope, don't think so. A "transaction", as in BEGIN TRANSACTION ...END TRANSACTION?

With transaction I ment the commiting of the child and parent data in one transaction (Tableupdates wrapped with BEGIN and END TRANSACTION) Since the key of the parent is not known to at least the TABLEUPDATE of the parent, I'm faced with the problem that I don't know the child FKs relating to the parent when the users enter the data.

>By using INSERT you could reference the value in the table without knowing its value. By committing the parent record first, the value should be available for subsequent commitment of child records.

In this way I'll have to write extra logic in the saving routine to insert the right FK for any child record that has been kept blank at data entry because it was not known at that time yet. This is not what I call progress. I do not face this problem with custom generated keys. When the parent is a local view, I also have to requery the view in order to capture the new PK, which have its own problems, because before the requery you don't know what PK is going to be assigned and will cause problems in determining what PK was used to save the record. I'd like to avoid these problems.

>We're both guilty of assuming something. I'm assuming that this is the way it will work when released, you're assuming it won't.

I am only trying to warn that the autoincrementing feature might not be what people think it is, and that they will be faced with problems that did not occur with custom generated keys. If it is just implemented as a counter in the tableheader, which is assigned when a record actually is written to the table (like in other DBMSs), I fear the worst....because people are going to use it, and will be faced with problems that are not easy to solve.

Walter,