6 Replies Latest reply on Oct 2, 2015 2:42 AM by Abingdon

    Globals and relationship problems?

    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.

        • 1. Re: Globals and relationship problems?
          wimdecorte

          Abingdon wrote:

           

          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.

           

          Despite what you think, someone else DOES have the record locked.

           

          Remember that if you edit a record in a portal you lock both the portal (related) record and the parent record

           

          Another common occurrence is that the record could be locked in an off-screen window if you use that technique in your scripting.

          • 2. Re: Globals and relationship problems?
            okramis

            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, ....

            This is what I do in my separation-modell dbs. On login I create a GUI-record with the MAC-adress as pk, so it's actually a record per machine. On logout I delete the record. FileMaker seems to lock the record also if a global is accessed (not that this makes any sense, as a global is individual for every session), so this seems to be the only way to prevent it.

            • 3. Re: Globals and relationship problems?
              Mike_Mitchell

              Wim is correct. Your problem is with the single parent record. I used to design things this way until I ran into this exact problem. You're right; global fields can be edited by any user, no problem, and editing a global field, all by itself, doesn't lock the record. However, as soon as you open a related record from a single-record parent, the parent record will lock if there are any non-global fields in it. So this won't work unless the single-record parent has nothing but global fields in it (which is the basis for the Selector-Connector model).

               

              Your other option is to use a session model, as okramis points out.

              • 4. Re: Globals and relationship problems?
                Abingdon

                Thank you Wim,

                 

                Thing is, the record is only being edited by one person, the designer.  They are indeed editing it in the portal. This of course has the effect of locking the parent record in addition but if absolutely no-one else is editing the record (or indeed, is even viewing the record)  I don't understand why I am getting this issue.  I have checked several times to see if anyone else is editing or in the record concerned but the answer is no.  It is also very odd that the Filemaker message is actually naming a conflicting User who not only is not in the record but has absolutely no access to that record because the record cannot be seen at all in their own portal.

                 

                I don't use an off-screen window for this but it is a very good point as I do use two windows, the main portal where the User clicks the chosen portal row to set the global to bring up the record's detail and a 2nd window to show that resulting detail of the same record - I wonder if that has something to do with it?  Would somehow refreshing/committing the first portal record help?

                 

                Many thanks again.

                • 5. Re: Globals and relationship problems?
                  PSI

                  Hi Abingdon, ( whatever happened to real names?)

                   

                  Your problem is having only one record in the Allocation db. This seems to make sense because you are only using global fields but as you can see as soon as you open a portal record things change.

                   

                  In the Allocation db create a 20 (or more) records. When the file opens put each designer on a different record. This can be accomplished by capturing the user count and incrementing it by 1. or you could add a Designer ID field, not global, which you need anyway. Store each designers ID in that field. when they login put them on the matching record.

                   

                  John

                  • 6. Re: Globals and relationship problems?
                    Abingdon

                    Dear All,

                     

                    Very many thanks for your helpful advice.  The record-per-user route is the one I will take and do away with the globals based relationships method.

                    Is there anything else I should watch out for/you recommend when making this change?

                     

                    Thanks again.