Hi Isabel,

There is no one good answer to this scenario. Are the primary keys data-bearing or surrogate? Meaning, are they keys that the user sees such as ID numbers or are they internal to the application and the user never sees them?

Another factor which comes in to play is the back-end database. Is this native VFP or SQL Server or Oracle or ???.

Finally, what is your UI paradigm for editing data with parent-child and parent-child-child relationships? This matters. If the user can simultaneously add/edit parents and children and (god-forbid) grandchildren this sets up a whole new set of problems.

Essentially, more precise information would help in helping you :-)

>In my application, I have a number of data edit forms which have parent/child and parent/child/child data relationships. I am getting the data through a middle tier, so am not pointed directly at the underlying databases. In most cases, the lists and records on the forms are aggregates of data from several normalized tables.
>
>I have been struggling with finding an clear, efficient and accurate way to handle tracking all my primary keys in the various add/edit/save/delete/skip situations. I'd love to handle them through a key handling class, but the whole process starts in the form Load, when you don't yet have much access to your form & its objects. As of now, I'm using a pair of set/get methods on the form to update an array of keys, with a little work on handling new keys being done in the business objects.
>
>I'd appreciate thoughts from anyone who's been down this road before. Are there any relevant design patterns you've used? How much of this have you left to the business tier to handle verus the client tier? I want as much of the functionality as possible standardized and pushed up into parent classes so special coding on each individual form is minimized.
>
>TIA,
>Isabel