Actually, it might be possible to related patient to Config under two scenarios:
If "changing config for a certain patient" can be done simply by linking that patient record to a different Config record. (This assumes that all values from config would change in a kind of "package deal" configuration change.)
If data from Config were used as a source of "look up" data copied from config. Then your config record works as a kind of "preferences" record where you can individually edit any given field in Patient that looks up such data when necessary.
If the relationship between patient and calc is one to one all of the above would also be true for linking calc to config.
There are two common ways to set up a source of default values. Both are variations of the same method:
1) When the file opens, a script loads a set of global fields with values from corresponding nonglobal fields in a record from a table set up for that purpose. This can be a non modifiable record set up by you (factor default) or a record modified by the user to suit their needs and purposes (user default). The non global fields allow you to modify the values from a client of a hosted database in a way that the changes will "stick" that doesn't happen when you directly edit the global fields from a client.
2) don't use the global fields, but set up relationships with enough table occurrences (often using the X operator) so that you get the same result as a set of global fields, but without actually using global fields as you now copy the data directly from the nonglobal fields in the table set up for this purpose.
The first 'IF' you cited may not work because there's the potential for the user to want different Config records for different calculations within the same Patient record. So overriding those preferences globally might mess up their Calcs.
A preferences system might work, but again, application of a different of a Config preference onto old records, though it would be useful for some scenarios, might be harmful generally.
When you say is Patient and Calc 1 to 1, do you mean 1 Patient record will be related to 1 Calc record? The latter could be 1 to infinite.
At the moment I'm inclined to think incorporating Config into Calc might be easier but I'd still like to have 2 defaults. From my comments above, which of your methods might work best?
Keep in mind that "preferences" are something that can be set to auto-enter into each patient record from global or related "prefernces" fields, but you can then edit the values for a given patient as needed.
do you mean 1 Patient record will be related to 1 Calc record?
I've never been able to figure out from your posts the exact purpose and function of your calc table. but given one to many as you specify, you'd need to set up some means for calc to copy over the current value for the parent record in patient before that record can use that data to match to records in Accret. Both calculation fields and fields with auto-enter settings can do that. Which is best depends one whether you need the values to automatically update in every related calc record when you change the corresponding value in your Patient record.
I attach a relationships graph. Calc fields Age and Sex are calculations derived from Patient and Calc::Std is from Config::Std. I had not realised that updating the Patient or Config fields only results in a correct Calc::Accret lookup if I set the former fields then make a new Calc record.
I assume that to avoid messing up old Calcs, making changes to Config must automatically involve having a new Config record, that I'll need to 'set' this to make it permanent and in doing so automatically generate a new Calc record.
assume that to avoid messing up old Calcs, making changes to Config must automatically involve having a new Config record,
Not necessarily. It depends on the option you set up for accessing the config data from calc. An auto-enter option such as looked up value or an auto-entered calculation will not update automatically when a value in config is altered. An unstored calculation that accesses the same field in config, on the other hand would update with each such change. (This is how we manage price changes in an invoicing system. The prices are "looked up" from a pricing or products table with an auto-enter field option and thus price changes don't alter the prices shown on pre-existing invoices.)
Having those options is useful. However, as I suggested, would you have to 'set' the Config, preventing changes for old Calcs, if you wanted the user to be able later to look at the Config settings that produced the results in the Calc?
Another minor query: What script step will update a conditional list displayed in a pop-up, when the underlying conditions have been changed; I assume it's a step that activates the pop-up (commit record/ refresh window don't do the trick).
commit records is the script step that should do the trick.
If you want to see previous config values, then yes, you'd need to keep that data in your database in one way or another, multiple config records is a likely approach for that.
I have the 2 fields that set the conditions working fine now (they'd needed to be global fields to avoid causing circular updating), but the popup only updates with the conditional list once I use it. Using 'onModify' commit records scripts on both the set condition fields (a radio-button and popup) doesn't automatically get the popup to show the updated list, instead it retains the __ID number from the last loaded record.
Sorry, but I just don't have enough detail about what you set up to be able to comment.
In the attached relationship graph, the Patient popup showing Names is conditional to 2 global fields, PatientStatus list (radio-button) and Location (popup). These 2 fields have a 'refresh window + commit record' script' 'OnObjectModify' trigger. However, on changing the PatientStatus list and Location conditions, the patient name (2nd field of value list) showing from the last conditional list disappears leaving its ID number (first field). Only when I click on the popup for patient names does the conditional list update.