If the solution files are all to be hosted on the same FMS (or same computer) then the field references need only be..
This is as lean and mean as it gets.
1 of 1 people found this helpful
...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.
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.
R J Cologon, Ph.D.
FileMaker Certified Developer
Author, FileMaker Pro 10 Bible
NightWing Enterprises, Melbourne, Australia
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.....