A client has Windows XP, and is experiencing the following problem.
1. He opens an FM Pro 4 database that has a relationship with another FM Pro 4 database.
2. When he clicks on the field that has the relationship defined, his Filemaker session times out.
3. Both database files are on his local drive.
4. The relationship is clearly defined as involving local files only, and the locations are correct.
5. When the action in step #4 above is taken, the Windows XP task manager shows two instances of Filemaker Pro, both "not responding". One of these instances is using "Filemaker Pro.exe" and the other is using "explorer.exe".
6. CPU utilization is not high during the time out period, nor are we experiencing "disk thrashing" on the local machines disk.
7. He has other databases that call the second FM Pro database (noted in step #1 above) and these databases do not experience the timeout.
8. I have changed the application preferences from TCP/IP to "none", restarted the application, and this tactic does not change the results.
9. If I disconnect this PCs network cable prior to the action taken above that normally results in a timeout, the response from the second database is instantaneous...no problem.
It appears that the action which results in timeout is prompting a search of some network asset...file, machine, folder, address, whatever. It appears that when this is made impossible, the Filemaker session does exactly what it is told to do, and opens the local files.
Normally, the customer will work off network files. The use of local files in these descriptive steps were part of my troubleshooting process. The effect is the same, for networked or locally held files.
My questions are these:
1. In lieu of anything obvious within the database relationships that specifies a non-local (network) asset, why is one attempting to be contacted (apparently). Do Filemaker Pro version 4 (I know this is several revisions back) record anything that cannot be viewed using the client tools?
2. Is there something about Windows XP itself that could be contributing to this problem? (The customer can run this process from a Windows 2000 PC without apparently problem).
Any help would be GREATLY appreciated.
Regards,
Dan
1. He opens an FM Pro 4 database that has a relationship with another FM Pro 4 database.
2. When he clicks on the field that has the relationship defined, his Filemaker session times out.
3. Both database files are on his local drive.
4. The relationship is clearly defined as involving local files only, and the locations are correct.
5. When the action in step #4 above is taken, the Windows XP task manager shows two instances of Filemaker Pro, both "not responding". One of these instances is using "Filemaker Pro.exe" and the other is using "explorer.exe".
6. CPU utilization is not high during the time out period, nor are we experiencing "disk thrashing" on the local machines disk.
7. He has other databases that call the second FM Pro database (noted in step #1 above) and these databases do not experience the timeout.
8. I have changed the application preferences from TCP/IP to "none", restarted the application, and this tactic does not change the results.
9. If I disconnect this PCs network cable prior to the action taken above that normally results in a timeout, the response from the second database is instantaneous...no problem.
It appears that the action which results in timeout is prompting a search of some network asset...file, machine, folder, address, whatever. It appears that when this is made impossible, the Filemaker session does exactly what it is told to do, and opens the local files.
Normally, the customer will work off network files. The use of local files in these descriptive steps were part of my troubleshooting process. The effect is the same, for networked or locally held files.
My questions are these:
1. In lieu of anything obvious within the database relationships that specifies a non-local (network) asset, why is one attempting to be contacted (apparently). Do Filemaker Pro version 4 (I know this is several revisions back) record anything that cannot be viewed using the client tools?
2. Is there something about Windows XP itself that could be contributing to this problem? (The customer can run this process from a Windows 2000 PC without apparently problem).
Any help would be GREATLY appreciated.
Regards,
Dan