I am seeking/building a Document Management System that allows healthcare patients to scan, store, view, and send medical records, using multiple selection criteria to filter desired documents. Below is my mockup ER.
Hi BlueSpruce,
At first sight of your diagram I thought that that all six related tables had the same structure, and thus ould be handled in the way of the Music sheets.
But then I saw it was only a mockup diagram, and all related tables have a different structure.
I agree, it is quite complex, especially with multi-selections form the same table.
Nevertheless, this kind of selection is standard available in all my applications.
To explain that, I have to go back in the evolution of my applications.
For the beginning on of my work with Access I have worked towards generalization. But only the forms were a hard nut to crack.
Then I realized that the binding of the form to the RecordSource was the killing factor in the generalization, and thus flexibilty. So I changed over to (User)control-binding. This means that the binding of a control is done on the moment that you focus on the control. With this binding the control knows where to get and store its value, but the control also knows how to act according to the user's wish, including the Before- and AfterUpdate functionality.
This makes it possible to use unbound forms, that are fully dynamical, completely independant of any data. In fact, the forms is "reduced" to a container with a number of anonymous controls, that are tuned with some generalized code, and displayed as such to the user. For all my applications I use only 2 forms: one continuous form, and one unbound form.
So, with this approach I can tune that one unbound form ready to make a dynamical SQL-string, for any table, with almost any condition depending on the usertype-definition for the fields. These usertype-definitions are more differentiated than the fieldtype definitions itself.
In my applications almost all underlying processes are generalized. This means that when starting with a new application, almost 90% of its future functionality is already there.
As an example the form to construct the WHERE-part of an SQL-string.
Focus is now on a "relation" (Vader), which happen to be the related records in the same table.
Further consequences of this approach is that I don't use Comboboxes, Subforms, Querydefs, Control classes, ... in trying to add more flexibility.
Imb.