AnsweredAssumed Answered

Globals and relationship problems?

Question asked by Abingdon on Oct 1, 2015
Latest reply on Oct 2, 2015 by Abingdon

FM14 with FMServer Advanced (although the same issue existed using FM11 and FM11Server).


Please forgive the length of this post, but I think it needs the detail.


Before I outline the problem I am having, the schema for my database is in part based on the premise that global fields can be used in a relationship if the global field is on the 'left-hand' of the relationship and the 'right-hand' field. i.e. the source table's field, is indexed.
At least this seems to be the case in my experience.


The database is being used by a design agency that designs leaflets for four clients.
Clients phone in their orders for design work - each client has its own discrete database where the orders are entered.  Each job has its own unique id.
There are therefore four database files that have no connection with each other, File1, File2, File3, File4.  These jobs are entered by a team of six admin staff.


The second part of the operation is the allocation of the jobs booked to an individual designer to produce the finished design.
There are 20 designers handling a total of approximately 200 jobs per day.

The design allocation is handled by a discrete'Allocation' file.

The pertinent part of this file is that it has a single record only, containing a number of global fields that are set by scripts so that the designers can see various portalled information from the four client job files.


The following applies to all the job files so I will limit the description to a single client job file, File1.

The physical allocation works as follows:

Admin pass a hard copy, printed Job Order to a designer.
Using a Filemaker script, a designer enters the unique id of the job in a global field in pop-up window - this allows them to check that the job they are about to allocate to themselves is the correct one.
The relationship here is 'gloidJob = File1::idJob'.
Once the designer is happy it's the correct job, a second 'Allocate' script then sets the designer's unique Userid into the an indexed field in the appropriate job record in File1.

The designer can then see their allocated jobs in a filtered portal using the relationship gloidDesigner = File1::idDesigner (the filter on the portal is set to show only job records that are set as 'In Progress' in the relevant job record.

So, designer Fred Smith can see his, and only his, jobs that he has allocated to himself.  No other designer can see another designer's jobs.


This portal has a second  function. By clicking on a portal row a script sets the unique Jobid into a global field, pops up a new window and, within a large single-row portal, shows the full Job details ready for editing as necessary (e.g. quantity or colour changes etc).
This relationship is same as previously mentioned 'gloidJob = File1::idJob'.


And this is where it (sometimes) breaks.  A designer, when attempting to edit one of their  job's details within this portal, will sometimes get the Filemaker message "This record is being edited by 'A.N. Other', you cannot edit this record until 'A.N. Other' has finished editing it."
The 'A.N. Other' is always another designer, not any other user.  The 'A.N. Other' designer is absolutely NOT editing that record, and neither is anyone else.
The designer receiving this message has to ask the 'A.N Other' designer to literally quit out of Filemaker so that they can edit the record.
This seems to happen more frequently the greater the number of designers that are logged into the system, but it does apppear a bit random.

I am at a loss to fathom this one.


I am thinking about rebuilding the Allocation file so that each designer gets their own individual User Record rather than all designers using the same single record, and then maybe also to do away with the global fields and use indexable fields here instead.

Thing is, as I am not sure what is causing the problem, I am not sure what the correct solution might be.


Thank you all for your patience and any advice you can offer me.