3 Replies Latest reply on Feb 9, 2012 10:45 AM by jeff777

    Weird ? issue with Source File in Table Occurrences

    jeff777

      I have a 45 file solution currently running on FM Server 11 Advanced that was originally built in FMPro 5-6 (by someone else). All of the External Data Source paths are set to use relative (file:filename) paths only, but the Source File listed in the TO's is using the "fmnet:/IPAddress/filename" path - in the case of one table its even "fmnet:/*/filename".

       

      Logically it seems this would be a performance problem if the db files, which are all in a single folder on the server, are having to resolve the fmnet path rather than just using the relative path. I know the * in the path is a major no-no.

       

      If I go to External Data Sources and add a source by navigating to the file through the Add File... > Remote selection, the file is added to Data Sources with the relative path, but the TO still has the fmnet path, so it's not just the pre-existing TO's - even the file with the * in the path comes over that way every time even though in the Open Remote dialog where I select it to add it displays the full IPAddress. So I can't just redo all the data sources.

       

      Never seen this before and can't find anything online. I manage/develop several other solutions and the TO's all use the relative path, so this concerns me. We're currently rebuilding to take advantage of more modern features and to address performance issues we're experiencing as we grow - so I want to get this right.

       

      If anyone knows what's going on - especially if there's a way to correct this, I'd appreciate any insight.

       

      Other details

      Files are named with an extension other than fp7

      DB files are on separate HD than FM Server (still on the same machine)

        • 1. Re: Weird ? issue with Source File in Table Occurrences
          Vaughan

          If the solution files are all to be hosted on the same FMS (or same computer) then the field references need only be..

           

          file:filename

           

          This is as lean and mean as it gets.

          • 2. Re: Weird ? issue with Source File in Table Occurrences
            RayCologon

            jeff777 wrote:

            ...If I go to External Data Sources and add a source by navigating to the file through the Add File... > Remote selection, the file is added to Data Sources with the relative path, but the TO still has the fmnet path, so it's not just the pre-existing TO's - even the file with the * in the path comes over that way every time even though in the Open Remote dialog where I select it to add it displays the full IPAddress. So I can't just redo all the data sources.

             

            Hi Jeff,

             

            The data sources as shown in the roll-overs on TOs in the graph are there for convenience and clarity, so they're set to translate relative file references into the actual/explicit full path at runtime (ie showing how the relative path has been resolved for the current file session) regardless of how the External Data Source has been defined.

             

            What matters from a performance perspective is what has been entered into the File Path List for each External Data Source, not the resolved path that's displayed in the Graph. The definition of the External Data Source path is what is used to locate the file and open it, so making it short, sweet and specific will have direct performance benefits. BTW, I would include relative references such as file:YourFile.xtn as short sweet and specific (ie I mean specific relative to the location of the hosted file, whether or not the path is fully specified...).

             

            So yes, you can and should redo the External Data Source definitions to ensure they are as consistent and specific as possible, eliminating wild-cards and using direct/relative paths wherever possible in place of network addresses. Given that the solution originated in fp5 format, you should also look for duplicate file references (ie separate External Data Source entries that refer to the same file by the same or different path/s) and ideally, you should edit all references to point to a single entry for each file and remove the redundant ones. If this wasn't done at the point of conversion to fp7, then it is a likely source of performance issues. Correcting it may be a sizeable undertaking, but can be expected to yield improved performance.

             

            Regards,

            Ray

            ------------------------------------------------

            R J Cologon, Ph.D.

            FileMaker Certified Developer

            Author, FileMaker Pro 10 Bible

            NightWing Enterprises, Melbourne, Australia

            http://www.nightwingenterprises.com

            ------------------------------------------------

            1 of 1 people found this helpful
            • 3. Re: Weird ? issue with Source File in Table Occurrences
              jeff777

              Thanks Guys

               

              The files are all on a single FMS and are all using the file:myfile format exclusively in the File Path List. Thanks for the insight on TO's displaying the resolved runtime path - that also explains why the other solutions I looked at used the relative paths - I access them remotely and run the cllient directly on the server - no network to traverse.

               

              This also led me to solve the issue of the wildcard in the network path for the one file. I hadn't considered that we use a very lean local launch file that opens a served file and then closes itself. The served file that it opens is the one that had the wildcard in the path. On examining the launch file it had fmnet:/*/filename as the Path (can't be relative because it's on the client desktop). Apparently once a file is openend on the server it keeps the path that was originally used to open it no matter which db you are viewing it from. Added the IP address so guess I'm as good as I can get.

               

              Learn something every day, which is why I love this stuff.....

               

              Thanks again