Thank you for your post.
Using a test machine here running Mac OS X 10.6.1 (Snow Leopard update) with FileMaker Pro 10.0v3 Advanced, I created a database file and a script that opens ten different remote files, on ten different servers all using FileMaker Server 10v2. When I run the script, it takes about five seconds.
When I bring that file to my iMac running Mac OS X 10.5.8, the script takes about four seconds to open the files. The speed difference might be attributed to a faster processor on my iMac. (2.4 GHz vs 1.83 GHz).
I don't doubt this is happening to you, so maybe you can provide a bit more detail.
Are you running Mac OS X 10.6 or 10.6.1 on the Snow Leopard machines?
Would it be possible to obtain clones of your files so I can try it here?
Is this all being done through an opening script? If so, can you turn on the Script Debugger and watch what steps are taking so long?
Any additional information you can provide may be helpful.
You might want to double check your external file references. Any servers now use a different IP address?
If there are any issues where the attempt to open a file requires FMP to work through an incorrect IP address before successfully opening the file with the next file reference in the definition, you can get significant delays waiting for the file to open.
Here's an example:
If the first reference fails, but the relative path works, FMP can take long time determining that the IP address reference doesn't work before moving on to the second reference.
Thank you for taking the time to simulate this problem.
The Filemaker Server is running on a PowerMac G5 Dual 2.5 Ghz, Mac OS 10.4.11. The client is an iMac 2.16 Ghz Core 2 Duo, Mac OS 10.6.1.
I did some more testing to try to find an explanation to this. To eliminate any user authentication issues, I copied onto my server the "Contact Management" file supplied in the templates folder, and opened it un-modified and no with no records. Next, on the client, go to "File/Open Remote" and open "Contact Management". Again with Filemaker with OS 10.6.1, I got a "beach ball" and it took a few seconds to open the file. On OS 10.5.6, it opened the file is a second.
No script is involved. It seems that external links, or user authentication have no effect.
Thanks for the additional information.
I'm still unable to duplicate this problem. I've accessed ten files on ten servers, and it is not taking long to open all ten.
Please create a new user account and try the same test. If it works correctly with the new user account, then there is something in the current account that is affecting access through FileMaker Pro. If it still doesn't work correctly, I would then uninstall and reinstall FileMaker Pro.
Do you have access to another Snow Leopard machine on the network? If so, would it be possible to try from that computer?
I'm sorry I don't have a clear cut answer for you. Snow Leopard is only three weeks old, and until someone else runs into the same problem, our knowledge is limited, especially when we are unable to replicate the problem.
We have the same problem. All DB references in our (quite large) database are done using FQDN only.
Opening sub-dbs sometimes takes a very long time, while FM is showing a spinning Beach ball.
The issue is mitigated somewhat by adding the DNS Name of
the filemaker host to the client's /etc/hosts or it's local directory using dscl.
Looks like FM is waiting for some system calls to return.
FWIW, i had a similar problem with FM8.5 ob Mac OS 10.3
(also solved by /etc/hosts).
FM Server is an Intel Xserve running 10.5 Server,
clients are diverse machines running 10.6. Network is fine otherwise.
Edit: I could provide an Instruments Trace File by Email.
Edit: This is my workaround, which speeds up things a bit:
dscl localhost -create /Local/Default/Hosts/filemaker.my.lan.net IPAddress 192.168.50.11
dscl localhost -create /Local/Default/Hosts/filemaker2.my.lan.net IPAddress 192.168.50.12
Thank you for your post.
Yes, I would like to see the Instruments Trace File. I have sent you a private message (top of this page - right side - X Messages) with instructions where to send the file.
On a similar issue, a customer was wondering why it took so long to open a single file not on the network. It turned out someone had created an opening script that was doing several finds and sorts before making the file available. Could this be happening with any of the remote files being opened?
We had the same issue.
And indeed replacing the DNS with an IP-address resolved the problem.
Just to clarify how to fix it exactly in the FileMaker file: you have to open the "Manage"->"External Data Sources…" dialog and adjust the file references there, so they do not contains a name, only an IP address.
Koen and I managed to solve the problem thanks to samosmatiker, I would like to add here that we didn't use the FQDN but just the netbios name, which resolves also on our Macs - the customer has a Windows network with a domain controller.
Another thing is that we had the "file:file.fp7" as the first line, and only on the second line the "fmnet:/fmserver/file.fp7" entry.
This because we wanted to be able to run everything locally, without the references jumping immediately to the server.
I think this shows, besides the fact that there seems to be a bug in the DNS resolving, that the application code is not optimally written. FileMaker is supposed to try to resolve the first entry first, and when that does not work, go to the next line, and so on. The file opens very slowly, which means that FileMaker is trying to resolve the second line, without even trying the first line.
One more update on this issue.
Apparantly, going through the file references with a snow leopard machine and resaving them did something to the file.
This morning Koen and I did some more testing, and we noticed that we could put the external references back to DNS names without slowing down the opening.
We can still reproduce the problem using a backup file from last week.
This means that the problem will be very hard to reproduce, because the observer is modifying the experiment...:-)
I hope this helps tracking down things.
just wanted to check if you received the trace file, and if there is anything else i should test...
My fault. I was unable to view the Instruments trace file, so I put it aside and forgot about it. My apologies.
When I double-click the trace file, Instruments loads but nothing occurs. Since I know little about Instruments, what are the exact steps to get this running?
Double-clicking the .trace file should open it in Instruments. Perhaps you have an older version of Instruments (i am using 2.0)?
The .trace file itself is really a bundle (you should be able to look at the "real" sample file by right-clicking on it and selecting "show package contents").
I am using Instruments 1.0. I'll find an update. I also received a second copy of your trace file.
I was finally able to obtain a copy of Instruments 2.0, and I see the information in your file trace file. I'll look it over for the next few days and see if anyone else can determine a possible cause.