I thought you might be interested in a GetAsText from the containerfile:British Airways.pdffilewin:/Z:/British Airways.pdf
The file is 107 KB and if I copy/paste it in the Window OS I can have the full copy in place in about 1.5 seconds - so there is no slowness in the file system.
Thank you for your posts.
I have been reading the post on Tech Talk, along with your comments today. I will make sure this gets reported today, and I'll keep you posted about any update.
Can you also try this directly with the server and not as a mapped drive? I'm expecting you'll get the same results, but I just want to be complete when reporting this. Thanks.
Sorry - I'm not sure I have the setup to do this additional check.
If you don't have the ability to change your setup, then don't worry about it.
At this time, there is no commentary from our Development or Testing departments.
Our Testing department has been unable to replicate the problem.
I also notice that the post on TechTalk was resolved as it turned out to be Mac OS X 10.4 server (10.5 worked fine). Since you are on Vista, this doesn't apply.
Have you been able to find a resolution?
I am having the same problem.
Client PCs: FM 9 on Windows XP
Clients have Gigabit network cards.
FM Server 9 on Win Server 2003 SP2
File Server: Win Server 2008 R2
However, a mapped drive is faster than UNC
Inserting a file reference though the network from \\networkedserver\folder\subfolder\file.pdf takes a minute.
Inserting a file reference through a mapped drive from n:\subfloder\file.pdf (where n:\ is mapped to \\networkedserver\folder) takes 10 seconds.
Inserting the same file, in either method above, as a file (not a reference) less than a second.
Any help is greatly appreciated!
Thank you for the additional information.
Although there is no additional information from the original poster, I have attached your post to the original case. If any information becomes available, I will let you know.
FYI I'm needing to map a drive on client PCs and hardcode the drive letter into scripts so that's a workaround but not ideal.
We also had the same issue. FM server 9 is on Mac. Mounted points are all in the same server holding original files.
FM Client 10, users are Windows XP users, when they try to open a link in FM record which points to the Mac Server mount points, takes 3-4 minutes to open.
Since today after all the test came up with that Windows (XP in our case) performs slow if there are huge number(4000+) of files, specially slower from FM client. When we moved all old files to another folder, workes everything much faster.
So it solved our problems. But we are handing invoice files, at this stage its not so important to access old files.
In other case, we have lots of MOV files, which needs randomly to be accessed, so moving old files to another folder is not a solution here.
My question is when I use Windows explorer/filemanager to access those files, takes just seconds, why it takes longer in FileMaker client(10.0.3)? May be the module/engine that FileMaker use to access windows filesystem(winfile://), is faulty or cannot handle larger amount of windows files efficiently.
I have finally, FINALLY stumbled across the solution to my problem I was also having with the agonizingly-slow InsertFile script step. In my case, working on a hosted database, the secret was in the External Data Source management !!
I was using two databases, one local and one remotely hosted on another machine, with the local database using the remote database as an External Data Source.
Original File Path List that allowed access to external data just fine yet caused MAJOR slowness using Insert File Script Step:
Modified File Path List that solved the problem:file:RelatedDatabaseNamefmnet:/192.168.1.108/RelatedDatabaseNamefmnet:/www.mydomain.com/RelatedDatabaseNameI needed all three because it will be used here locally (where the FMServer is located) as well as externally by other clients using the domain name.Now the script takes less than 1 second, as it well should, where before it was taking 20-30 seconds each time it ran, causing the spinning beach ball-of-death and lots of finger tapping while uttering vocabulary not fit for fellow workmates...