Something has gone south in my relationships and I'm at a loss as to where I should go to fix this. Two files use basically the same relationships and when I open either, I might as well go jog around the building for as long as it takes my system to open everything up. Once open, performance is fine until I go to define relationships.. then it takes forever for that to finish opening. But the real kicker is, it's only on my machine. The rest of the users have normal functioning still.

I've cleared temporary files and still have had no luck. Anyone out there seen this before and know what to look for?

Are the files hosted via Server or client? If client, are the files on a remote or local volume?

Server... I've cleaned out all the temp files, uninstalled 5.5 Developer and reinstalled & patched 5.5v2. I'm at a loss as to why I'm the lucky one on the whole network. And I'm the one who developed the darn databases to begin with. They've been in use for two years now and just show this problem. Very frustrating to say the least.

When looking at a network packet capture, I seem to see where it bogs down. I can see my layouts coming across. I can see my formulas and data coming across. Then it seems to have trouble with my related files.

See the example below. These paths listed are old and no longer exist on my machine. It appears to finally see that the files are on the FMPro Server and everything works fine from that point on. But if you close out of the file and reopen it, it starts hunting for it all over again.

Is there anyway to remove this path information for databases that are hosted by FMPro Server? If it's spending time searching all these different paths, that could explain why it takes me forever and a day to start these databases.

Example:

=========================================================

FPTH

1SPAT

RPTH

SRPT

NAME

WSPC

FPTHA1STORAGE:My Documents:conversion:Product Table.fp5

NAMEA Product Table.fp5

RPTHA PRODUCT TABLE.FP5

SPATA&STORAGE:MYDOCU~1:CONVER~1:PRODUC~1.FP5

SRPTA.PRODUC~1.FP5

WSPCA.E:My Documentsconversion

QUERY_PATH_INFO (2 TIMES)

QUERY_FS_INFO (4 TIMES)

QUERY_PATH_INFO (2 TIMES)

QUERY_FS_INFO (4 TIMES)

QUERY_PATH_INFO (2 TIMES)

QUERY_FS_INFO (4 TIMES)

QUERY_PATH_INFO (2 TIMES)

QUERY_FS_INFO (4 TIMES)

FPTH...

3SPAT...

RPTH....

SRPT....

NAME....

WSPC.....

FPTHA3Telescript:Vista Order Processing:Batch Records.fp5

NAMEA..Batch Records.fp5

RPTHA.BATCH RECORDS.FP5..........

SPATA Telescript:VISTAO~1:BATCHR~1.FP5

SRPTA.BATCHR~1.FP5

WSPCA.K:Vista Order Processing

============================================

I had a similar problem a few years ago. The files opened quickly on the server, but took ages to open locally. It stumped the experts at DevCon. It turned out there were references to files on the server, as well as references to the files on my hard drive. So opening them on my machine confused FM on where the files should live.

I believe you have two options. One is to take the files off the server, save them locally, open them all in single-user mode (or change them to it if you have no on open script to change them), re-establish the relationships and script calls with 'Save relative path only' checked. The other would be to re-establish relationships and script calls specifically using the server's ip, so that when you close and reopen a script, any external script calls and open/close steps contain an ip address after them. As long as you don't end up with an asterisk after the steps, I think you'll be okay. An asterisk seems to indicate that FM will look anywhere on the network for the file and open the first one it finds or one that's already open.

Also, make sure you have no copies or clones of the files on your local drives that use the same name as those on the server. A good rule of thumb is to never have two FM files with the same name anywhere on your network. Always zip or stuff copies with the same name and delete the copies afterward.

Looks like this behavior was addressed in Filemaker Pro 7. File references can be viewed and directly edited by the user. Now if only someone had a utility to do a backdoor fix for those of us on 5.5.

http://www.filemaker.com/ti/108758.html

FYI: Filemaker Support suggested http://www.metadatamagic.com for fixing the file reference issue in older databases.