Hiya John :-)
To take your comments in turn....

>Hiya Barbara ---
>
>In good database design theory, every table should have a unique, primary key -- right? So....in my frameworks I have a generic INSERT INTO table (primarykey) VALUES (whatever). Now, the particulars are dependent on certain property settings but you get the picture.
>
>I could *never* use an APPEND BLANK in my framework because even the thought of APPENDing a blank into a table with a primary key gives me the willies. Surefire way to invite the dreaded "Primary key violated" error!

As Mark W. also said, this isn't a problem with a stored procedure for the primary key. Your point about 'hiccups' in the stored procedures is well taken, but I haven't seen that in VFP5. It was common in VFP3, but we've had no problem with it despite our heavy network problems of the past 5 months. Of course, I'm using INSERT in almost every place.....

>And now I'm curious: Why could your "Add" button be confused? Are you using context-sensitive controls? I've never been able to get away with that...most of my users hate that in general.....

Yes, by user request. This is a high-speed data entry screen and the specs included: 1 screen (no pages), grid for child records, Alt-A keystroke OR mouse click on the ADD button to add a record which would be CHILD if you were in the grid and PARENT if you were on a non-grid control. Also a down-arrow from the bottom grid line would add a child record and put the cursor on the first column. NOT my favorite user interface, but the client calls the shots.

Barbara