Can you describe this part of the issue in more detail?
when one user is looking at a record, if another user changes the layout on 'their' instance, (different user account) the layout will change across each persons screen currently looking at that layout.
How are they "changing the layout"? Are they selecting a different layout from the layout drop down? Clicking a button?
Or are they modifying the data on the screen in front of them?
What change do the other users see?
Does the data shown change or are they suddenly on a completely different layout?
thank you for your reply.
the calendar is displayed using portal filters. one of the filters is Table1::appointment_location = Table2::appointment_location, then display....
when one user changes the location they are looking at, it changes across all users viewing that layout. they change by clicking the button that launches the script to go to that layout, or within the layout I've placed a drop-down box for fast switching.
the change others see is that is switches to reflect the last-selected appointment location.
the layout does not change, just the data displayed
Your database is doing exactly what you designed it to do. It's just not doing what you expected it to do.
If a user modifies data in a given record on one machine, others will see the same changes to that data--it's the same record after all. So if one user changes the value used in the filter, the data displayed in the portal will change for all users.
There is a way to get around that issue, however.
Use a field with global storage in place of whichever of those two fields is NOT from the portal's table. Changes to global fields are not visible to other users and so eachuser can then see different data in the filtered portal.
I figured it was me...
I'm a little confused however, I don't think I can change the field NOT on the portal table, it's being populated at the time the appointment is setup. Wouldn't changing it to a global storage field impact existing data and then affect they way data is stored from now on?
the tables and fields we're discussing are Appointments::Appointment_location and (portal table) Interface::Appointment_location. the Appointmens table is populated by script once details are entered on the data entry layout and a button called "set appointment" is pressed.
should i create a different table, create a field that simply mirrors the Appointments::appointment_location field and use that in the portal filter?
Wouldn't changing it to a global storage field impact existing data and then affect they way data is stored from now on?
Because it is a global field modified by a client, not the host, No.
Before I can answer any other questions, Why would a user modify the appointments::appointment_Location field so that the portal lists different data?
The portal refreshes based on changing Interface::Appointment_Location. That is the field on the layout that links to the Portal Table. (see screenshot)
appointments::appointment_location is changed when data entry is taken.
they modify the location pop-up (it's tied to the 'portal' table). When changed, a portal refresh is initiated and a new filter is applied, ie.
Interface::Appointment_Location = appointments::appointment_location
Appointments::Appointment_Date = Interface::cDateOfFirstPortal +4 ; 1 ; 0)
this was coded to allow changes to the location calendar without returning to the data entry screen. There are 9 locations for which this office shcedules appointments.
does this make sense?
my concern was changing the appointments::appointment_location to a global field, and whether or not they would lose the data there as that would be disastrous.
thank you so much for you assistance.
If I understand your last post, the field that should be made global is the Interface::Appointment_Location field, not the appointments::appointment_location field.
The large "Colin-M" field in the top left corner is Interface::Appoitnment_Location and if you go to Layout setup...|Show Records from, you see "Interface" in that drop down?
If so, then make Interface::Appointment_Location a global field and each user can see different data without 'colliding' with data changes made to this field by a different user.
Here's a link to a knowledge base article on global fields that you may find helpful: http://help.filemaker.com/app/answers/detail/a_id/5895