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!
So I guess I concur with your INSERT theory.....
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.....
>Nope, only the "append a new record and fill in the needed keys" portion is a snap with INSERT INTO. All the remaining part - getting the grid to refresh correctly, handling combos and other non-textbox controls, making sure the ADD button knows whether you're adding a new child record from the grid or adding a new parent record from the remainder of the form (no pageframes for this client) etc. - are STILL a real hassle :-)
>
------------------------------------------------
John Koziol, ex-MVP, ex-MS, ex-FoxTeam. Just call me "X"
"When the going gets weird, the weird turn pro" - Hunter Thompson (Gonzo) RIP 2/19/05