5 Replies Latest reply on May 8, 2013 8:02 AM by Norsult

    Open File with same Name from two different servers on one client and loose control

    Norsult

      Something strange is happening in some (not all) of our test and client environments.

       

      A solution (one file) is hosted on serveral servers, with slightly different versions of the FileMaker database file (same filename still) and off course completely different data.

       

      When clients with a slow connection with high latency to one of the servers connect on a faster path to the another server, their data gets seemingly mixed (it appears so on screen); relationships seem to be gone, fieldlabels with programmed values disappear and even the scriptdebugger shows only parts of a script and then jumps out to exit a script without finishing.

       

      After quitting FileMaker (Client), reloading the programm and connecting to only one server at the time, data seems to be intact except for the scripted process that went weird.

       

      Has any of you seen something like this?

      Any knowledge about FileMaker getting hickups with two files with the same name opened from distant, separate servers concurrently?

       

      Just throw in your experiences. We do continue testing and tracking down the events and the participants to get a better understanding of what is going on.

       

      Briefing to tech details: all clients various current MacOS Systems (Lion and Mountain Lion mixed) running FMP (A) 12.0v3

      Servers: MacOS (Lion), MacOS (Mountain Lion) Windows Server 2008, some with FMS , some with FMSA, all Version 12.0v3

       

      Thanks for your attention!

       

      Volker

        • 1. Re: Open same solution from two different servers on one client and loose control
          Stephen Huston

          You may have some FileMaker External Data references which use the network-file format in your system. Those will search the FM network for any available file of that name rather than just the file in the same directory. Try cleaning up any data references where the Net or Network format of the file reference is used to stop the network-searching.

          • 2. Re: Open same solution from two different servers on one client and loose control
            Norsult

            Thank you Stephen.

            But, as I said, a one file solution – so no external references to network files.

            • 3. Re: Open same solution from two different servers on one client and loose control
              LyndsayHowarth

              I'd still check the external references...

              ... and save a compressed copy...

              ... and run a DDR to see if there are any paths...

               

              What's in the 12.0v4 update?

               

              The thing is... did you have data for one host in it then clone/copy the file for the next host? I suspect so if it is clinging on to historical paths.

               

              good luck...

               

              - Lyndsay

              • 4. Re: Open same solution from two different servers on one client and loose control
                Norsult

                Just doing that, Lindsay, using a fresh DDR in BaseElements.

                 

                And yeah, what's in the 12.04 Update? After the desaster with server update to 12.04 I'm still waiting. And FM Inc. does not say very much about changes.

                 

                And yes, the Versions on different machines are all copies (clones) of the same file originally.

                 

                I'll keep you informed.

                 

                Volker

                 

                --edit a minute later--

                 

                there is only one correct relative file reference in the whole thing pointing to the "Documents" file (a FMP12 file) on the same host.

                In none of the cases this file or reference to it was involved.

                 

                • 5. Re: Open same solution from two different servers on one client and loose control
                  Norsult

                  ...and here are some interesting findings...

                   

                  Recap: The file "MyFileName" is open in a local client, hosted from ServerOne. Another instance of a file with the same Name "MyFileName" is hosted on ServerTwo. Also this is open in the same client.

                   

                  Both files contain the table "MyTable" with datafields from that table(occurence) in a layout named "MyLayout". But the contents of "MyTable" is different in the two versions and some fields exist in one but not the other files' table.

                   

                  Now do the following. Goto the layout "MyLayout in a window that belongs to file that you opened last. Then open the data viewer and retrieve the fieldnames on that layout with

                  Getfieldnames ( Get (FileName); Get (LayoutName))

                   

                  This returns a list with so many entries as there are fields on the layout. Some of the entries are blank! An entry is blank for all the entries that exist in the last opened file but are not contained in the first opened file.

                   

                  Now close the first file, and reevaluate in Data Viewer: voìla - all fieldnames come up.

                   

                  Reopen the first file, ot the corresponding layout in the first file and look what happens in Dataviewer: a mixture of the two results appears; all fieldnames always appear in the same order, now in the last case with gaps in new places.

                   

                  Conclusion:

                  Again we guess what happens. FM gets the fieldIDs of the elements on the layout in the place where we want it to look. FM builds a list of these IDs. It then retrieves the corresponding names for the ID, leaving an empty space where no name is found - because it appearantly looks in the table definition of the wrong file!!

                   

                  We start now testing with the current release of FM 12.0v4 to see if this was a problem acknowledged and silently solved or if it still persists.

                  In the later case we would prepare a test file set and make a bug report.

                   

                  --- tested in 12.0v4 --    

                   

                  The same reproducable (mis-)behaviour!