find vs matching relationships

[lsmall]

This is difficult to describe and perhaps difficult to answer in a forum, but I'll give it a go. I have a complex database that collects information on medication use in a hospital. Each occurence of a medication is its own record in the drug table and is associated with a patient and a date. Everyday that that medication is active for that patient will generate a new record. I generate charts of specific medication use. To do this I have a global check box field with all medications of interest and global fields to create a date range. The check box field is related to the medication field and via a relationship will generate a chart of only the checked medications in the check box field. The date range works the same way. So these selection fields are not find fields, rather they are global fields with relationships to the record fields.

This works just fine except for one flaw. At some point I will want to have this available on a network where mutiple users may work on it simultaneously. The set up I have now will fail since a second user can change the relationship set up by the first user using the global fields.

So how can I set up a similar check box field that functions as a find? A find will try to match records that have all of the checked meds in one record, which will never happen since by definition every medication occurence is its own record. So I need a type of "quick pick" find field that will operate with "OR" functionality rather than "AND". I'm sure there are multiple ways of doing this, but I just haven't come up with any that work as well as my current relationship method.

I hope I have explained this well. If I need to elaborate let me know.

Thanks

[IdealData]

The set up I have now will fail since a second user can change the relationship set up by the first user using the global fields

I think you are misunderstanding global fields...

If you have created the globals to be the "parent" in the relationships then you have no problems because global fields are unique to EACH USER in a networked environment.

The FM explanation which says:

"A field that uses global storage contains only one value that is shared across all records."

is quite true, however it fails to point out that this is from the aspect of each individual user.

[lsmall]

Really!

That's great to know. Is this true of any method of networking? i.e. client/server, FMserver-php, IWP? Currently I use IWP to allow others access to the database, but I may look to higher functionality in the future.

[Søren Dyhr]

Is this true of any method of networking?

It is, if the solution is properly shared - which in this case means no os-level filesharing!!

If you have created the globals to be the "parent" in the relationships then you have no problems because global fields are unique to EACH USER in a networked environment.

While it's true as such, must the deployer be aware if a solution goes from being a single user to a peer to peer shared, will the initial value for the global be what was in the field latest when multi user scenario began. This means that a good policy could be to think of which value to load into the global in the initiation script.

--sd

[lsmall]

This means that a good policy could be to think of which value to load into the global in the initiation script

Yes, my initializing script sets defaults for the global fields.

Edited November 16, 2009 by Guest

[IdealData]

Is this true of any method of networking?

Yes, it is.

If you really want to test it then get the free trial download of FMServer or FM10 from the FM website.