Hi Ed,

Thanks for the input. The example I gave was pretty much an over-simplification of how I designed the software. There are multiple levels of complexity including readmissions and reoperations. I've pretty much handled every possible scenario as far as when and where procedures may occur. My main concern was whether the persistent relationship design would result in inconsistent behavior during runtime. Although the key is unbalanced, I'm primarily going to be using it to retrieve and display the child procedure records within the interface. Report access to this particular table will be through SQL statements, cursors, and views.

In the future, I hope to use more of your advice in incorporating p-views into the interface and better management of keys/relationships. I've never had a prior situation where I have to build relationships such as this one. To be honest, this particular medical application has been a nightmare. Each patient record has about 20 different source tables being displayed through the interface. This is the first heavy duty application that I have built with VFP, and I'm just hoping that everything holds up during runtime. Most of my previous applications have been built with MS Access. Access makes some things easier, especially the relating, retrieval, and display of data. However, it doesn't have the capacity and flexibility of VFP in most other situations.

As far as using Social Security numbers for the patient ID, I discussed this with the client. The client only works with a particular demographic range of patients, all of which have social security numbers. Thus, it was easier for me to just use the soc. sec. number as the ID. In other situations, I probably would not have used this as the ID.

Dave