>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 :-)
>>
Ok, lets think about the job responsibilities of the back-end in a modern-day program: it is responsible for making sure its data ok. Furthermore, it's NOT the job of the middle-tier to ensure that your data is valid: like I said, that's the job of whatever back-end you're using.