Filemaker (-1072) Problem

TheOpenMind · 08-02-2005, 01:16 PM

I've been using a shared filemaker 6 client to handle a contacts database for about a year now. Everything has worked fine until just recently. Filemaker began giving me this Error Message "Communication with host was interrupted and could not be re-established (-1072)". I've tried re-installing the application on the host machine, but no luck. The message will appear about 2-3 times a day and close filemaker. The rest of the time, it seems to work fine.

I know this seems more of an app specific question, but my real question here is do you think it could be failing hardware?

Any help is greatly appreciated!

AHunter3 · 08-03-2005, 08:09 AM

It could be (I'd start off with ethernet cables and/or airport h/w, hubs and/or routers). FileMaker is more network-intensive than the vast majority of TCP-dependent apps. When you fetch/send email or open a new web page, you make a connection only long enough to load the next page or make the POP negotiations, and those apps are generally patient and forgiving when packets are not forthcoming (you just get wrist-watched or beach-balled for a bit). FileMaker, on the other hand, is much chattier between client and host and does not like it when communication doesn't continuously flow. Do you get a lot of the wiggly-arrow "waiting for network responsiveness" cursors as you work, in addition to the "Communication interrupted" dialogs?

TheOpenMind · 08-03-2005, 02:34 PM

Not Really, for the most part, Filemaker works great and operates incredibly quickly. Although our DB is only contacts and therefore we don't spend much time entering data anymore.

AHunter3 · 08-03-2005, 03:32 PM

Do I correctly understand that the file is being hosted via plain-vanilla FileMaker Pro, not FileMaker Server? Peer sharing, in other words?

How is machine #2 (the guest/client machine) opening the file? By going to File, selecting Open, clicking "Hosts", and selecting the file when it appears? By double-clicking a file that has a script that opens the remote file? Or by mounting the drive of machine #1 (the host machine where the database is located) and double-clicking on the actual filemaker database file?

If the lattermost option, stop doing it that way (bad practice).

If I've misunderstood and you have the solution hosted on a FileMaker Server box: unserve the file and open it in plain-vanilla FileMaker and check the Access Privileges. Is the checkbox for "disconnect on idle" checked, as in this pic? If so, uncheck it.

If it's peer sharing and the guest machine is opening the file in the proper fashion (File, Open, Hosts): is machine #1, the one hosting the database, being used for lots of other functions? Is it someone's regular workstation, for example, or is it being used as a mail server, file server, etc? Other threads and processes, especially if they involve networking, can starve Filemaker and cause it to lose the connection.

How about backup software? Does the host machine have automated backups running that try to back up the still-running Filemaker file (along with the rest of that hard disk)? That'll cause you bigger problems than just disconnecting your clients. You corrupt Filemaker files when you continually copy them while they are open and running. (And the backups won't be in anything approching pristine condition either).

TheOpenMind · 08-03-2005, 05:09 PM

First, yes the host of the file is a plain non-server version of Filemaker Pro 6. It's a small business with less than 10 users and so server didn't seem a justifiable option.

Second, The File is being accessed via an alias to the original copy. Typically we just put a link to the file in the document section of our dock. It seemed to work fine and was easy to use. I was unaware that this was a bad practice. Could you elaborate? And how would one go about scripting a logon?

Third, The host machine is a 733mhz, Gigabit Ethernet mac running Mac OS X.3.9, and it is used as a file server. I don't think that the network activity is starving filemaker because this is the same network that worked for nearly a year prior to the problems starting.

And Lastly, We do backup, but it is done manually, and, when we run backups, filemaker is closed.

TheOpenMind · 08-03-2005, 05:37 PM

I couldn't check at the time of the last post (b/c people were using filemaker and, without server, you can't change preferences while a file is shared), but the option "Disconnect From Server When Idle" is available in the plain filemaker client in File->Access Privledges->Passwords. I made the change and now will wait to see if that fixes the problem. Thank You for the help!

AHunter3 · 08-03-2005, 10:15 PM

Quote:


	And how would one go about scripting a logon?

Create new database file (on a machine OTHER than the host box). Exit the "Define Fields" dialog (you don't need fields). Define one script. In that script, define two script steps:

Perform Script — pick "Remote Script" — indicate that you want to change files to pick a script in a different file — click "Hosts" — pick the running file when it shows up. If it's on a different subnet you may need to click "Specify Host" and type in the IP address of the server to cause the running file to show up. After you select the file, you'll get access to the scripts within that file. Pick a good script to run upon solution-opening.

All that is the first script step.

The second script step is simply "Close".

Now go to Preferences; Document Preferences; indicate that you want this script to fire whenever this file is opened.

Now distribute copies of this file to each workstation that people use as a guest of the host computer, to open the database.

TheOpenMind · 08-04-2005, 12:34 PM

Okay, I understand how to script the opening, but why would I do this over simply using an alias to the original? Using an alias is fast (and will be faster than the script!) and hasn't created any problems as of yet. Are there reasons not to open by double-clicking the original document?

AHunter3 · 08-04-2005, 02:22 PM

FileMaker database itself is on the hard disk of Computer #1, you're using Computer #2:

• You double-click the alias on Computer #2. Your own OS responds by first launching the appropriate app for the file (FileMaker Pro) and then attempting to open the alias target (the remote file) with that app. File is in use, but because FmPro is a multi-user app it does not throw an "ERROR — file is open or in use" message in your face and instead does internal redirect, to handle it as if you had tapped politely on the metaphorical shoulders of the copy of FmPro running on Computer #1 and said "I'd like to open this file as a guest". It may seem that from that point onward, the result should be identical (you, on Computer #2, are in the file as a guest of Computer #1) but reports from developers indicate this may not be so. On some level, in some fashion, Computer #2 continues to flush data or send requests up the line as if Computer #2 were the sole user of the file, and all such traffic has to be redirected/reconfigured by FileMaker on Computer #1. And the file sharing protocol invoked by the alias is AFP-over-IP. The native FileMaker file sharing protocol is not. (It is, in fact its own protocol. fp5://your.server.ip/filename is an URL distinct, and distinctly different, from afp://your.server.ip/filename).

So there's constant overhead. In particular, your OS tries to flush writes directly to the mounted hard drive of Computer #1 (the equivalent of saving a changed file to disk, except that FileMaker does it constantly as you work) but all such writes are the exclusive province of the host copy of FileMaker. Have to be. Think about it.

• One fine Tuesday you double-click the alias. For unknown reasons, the FileMaker database is not open and running on Computer #1. Your OS obligingly launches FmPro and then opens the file. You get a warning message that you're about to become the host of a remote file. Are you FmPro-savvy enough to know what a phenomenally bad idea it would be to OK this and proceed anyhow? Let's say for the sake of argument that you ain't. Or that Joe Coworker has for some reason sat down at your computer for a quick peek at the database and Joe isn't FmPro-savvy enough to know not to hit the OK button. It gets worse. Does Susie Coworker on Computer #3 also have such an alias? If she does, and double-clicks it now, she becomes a guest of you as a remote host of a file on Computer #1. Or perhaps the dude who uses Computer #1 comes back from lunch and double-clicks the local file. It's already open — by you. So now the computer that physically holds the file becomes a guest of you, the remote host of a file residing back on Computer #1.

FileMaker is very network-intensive. Chatty. Constant communication between guest and host. Constant flushing of guest cache to host cache, and of host cache to hard disk. Constant new reads of data on hard disk into host cache. You really don't want to know what a snarled-up mess the packet-path ends up looking like in a case like this. Drop a few packets and say hello to file corruption.

The method I outlined is a PITA to set up but should be quite fast once set up: you double-click the local file, it opens in FileMaker, opens the real file over the network for you (always as a guest, using appropriate guest protocol), and then closes itself. It should not be any slower than double-clicking an alias to the file. It should, in fact, be faster.

Thread Tools
Show Printable Version Email this Page
Display Modes	Rate This Thread
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode	Rate This Thread:

08-02-2005, 01:16 PM	#1
TheOpenMind Triple-A Player Join Date: Mar 2005 Posts: 51	Filemaker (-1072) Problem I've been using a shared filemaker 6 client to handle a contacts database for about a year now. Everything has worked fine until just recently. Filemaker began giving me this Error Message "Communication with host was interrupted and could not be re-established (-1072)". I've tried re-installing the application on the host machine, but no luck. The message will appear about 2-3 times a day and close filemaker. The rest of the time, it seems to work fine. I know this seems more of an app specific question, but my real question here is do you think it could be failing hardware? Any help is greatly appreciated!

08-03-2005, 08:09 AM	#2
AHunter3 Hall of Famer Join Date: Jan 2002 Location: New York City Posts: 2,798	It could be (I'd start off with ethernet cables and/or airport h/w, hubs and/or routers). FileMaker is more network-intensive than the vast majority of TCP-dependent apps. When you fetch/send email or open a new web page, you make a connection only long enough to load the next page or make the POP negotiations, and those apps are generally patient and forgiving when packets are not forthcoming (you just get wrist-watched or beach-balled for a bit). FileMaker, on the other hand, is much chattier between client and host and does not like it when communication doesn't continuously flow. Do you get a lot of the wiggly-arrow "waiting for network responsiveness" cursors as you work, in addition to the "Communication interrupted" dialogs?

08-03-2005, 02:34 PM	#3
TheOpenMind Triple-A Player Join Date: Mar 2005 Posts: 51	Not Really, for the most part, Filemaker works great and operates incredibly quickly. Although our DB is only contacts and therefore we don't spend much time entering data anymore.

08-03-2005, 03:32 PM	#4
AHunter3 Hall of Famer Join Date: Jan 2002 Location: New York City Posts: 2,798	Do I correctly understand that the file is being hosted via plain-vanilla FileMaker Pro, not FileMaker Server? Peer sharing, in other words? How is machine #2 (the guest/client machine) opening the file? By going to File, selecting Open, clicking "Hosts", and selecting the file when it appears? By double-clicking a file that has a script that opens the remote file? Or by mounting the drive of machine #1 (the host machine where the database is located) and double-clicking on the actual filemaker database file? If the lattermost option, stop doing it that way (bad practice). If I've misunderstood and you have the solution hosted on a FileMaker Server box: unserve the file and open it in plain-vanilla FileMaker and check the Access Privileges. Is the checkbox for "disconnect on idle" checked, as in this pic? If so, uncheck it. If it's peer sharing and the guest machine is opening the file in the proper fashion (File, Open, Hosts): is machine #1, the one hosting the database, being used for lots of other functions? Is it someone's regular workstation, for example, or is it being used as a mail server, file server, etc? Other threads and processes, especially if they involve networking, can starve Filemaker and cause it to lose the connection. How about backup software? Does the host machine have automated backups running that try to back up the still-running Filemaker file (along with the rest of that hard disk)? That'll cause you bigger problems than just disconnecting your clients. You corrupt Filemaker files when you continually copy them while they are open and running. (And the backups won't be in anything approching pristine condition either).

08-03-2005, 05:09 PM	#5
TheOpenMind Triple-A Player Join Date: Mar 2005 Posts: 51	First, yes the host of the file is a plain non-server version of Filemaker Pro 6. It's a small business with less than 10 users and so server didn't seem a justifiable option. Second, The File is being accessed via an alias to the original copy. Typically we just put a link to the file in the document section of our dock. It seemed to work fine and was easy to use. I was unaware that this was a bad practice. Could you elaborate? And how would one go about scripting a logon? Third, The host machine is a 733mhz, Gigabit Ethernet mac running Mac OS X.3.9, and it is used as a file server. I don't think that the network activity is starving filemaker because this is the same network that worked for nearly a year prior to the problems starting. And Lastly, We do backup, but it is done manually, and, when we run backups, filemaker is closed.

08-03-2005, 05:37 PM	#6
TheOpenMind Triple-A Player Join Date: Mar 2005 Posts: 51	I couldn't check at the time of the last post (b/c people were using filemaker and, without server, you can't change preferences while a file is shared), but the option "Disconnect From Server When Idle" is available in the plain filemaker client in File->Access Privledges->Passwords. I made the change and now will wait to see if that fixes the problem. Thank You for the help!

08-04-2005, 12:34 PM	#8
TheOpenMind Triple-A Player Join Date: Mar 2005 Posts: 51	Okay, I understand how to script the opening, but why would I do this over simply using an alias to the original? Using an alias is fast (and will be faster than the script!) and hasn't created any problems as of yet. Are there reasons not to open by double-clicking the original document?

08-04-2005, 02:22 PM	#9
AHunter3 Hall of Famer Join Date: Jan 2002 Location: New York City Posts: 2,798	FileMaker database itself is on the hard disk of Computer #1, you're using Computer #2: • You double-click the alias on Computer #2. Your own OS responds by first launching the appropriate app for the file (FileMaker Pro) and then attempting to open the alias target (the remote file) with that app. File is in use, but because FmPro is a multi-user app it does not throw an "ERROR — file is open or in use" message in your face and instead does internal redirect, to handle it as if you had tapped politely on the metaphorical shoulders of the copy of FmPro running on Computer #1 and said "I'd like to open this file as a guest". It may seem that from that point onward, the result should be identical (you, on Computer #2, are in the file as a guest of Computer #1) but reports from developers indicate this may not be so. On some level, in some fashion, Computer #2 continues to flush data or send requests up the line as if Computer #2 were the sole user of the file, and all such traffic has to be redirected/reconfigured by FileMaker on Computer #1. And the file sharing protocol invoked by the alias is AFP-over-IP. The native FileMaker file sharing protocol is not. (It is, in fact its own protocol. fp5://your.server.ip/filename is an URL distinct, and distinctly different, from afp://your.server.ip/filename). So there's constant overhead. In particular, your OS tries to flush writes directly to the mounted hard drive of Computer #1 (the equivalent of saving a changed file to disk, except that FileMaker does it constantly as you work) but all such writes are the exclusive province of the host copy of FileMaker. Have to be. Think about it. • One fine Tuesday you double-click the alias. For unknown reasons, the FileMaker database is not open and running on Computer #1. Your OS obligingly launches FmPro and then opens the file. You get a warning message that you're about to become the host of a remote file. Are you FmPro-savvy enough to know what a phenomenally bad idea it would be to OK this and proceed anyhow? Let's say for the sake of argument that you ain't. Or that Joe Coworker has for some reason sat down at your computer for a quick peek at the database and Joe isn't FmPro-savvy enough to know not to hit the OK button. It gets worse. Does Susie Coworker on Computer #3 also have such an alias? If she does, and double-clicks it now, she becomes a guest of you as a remote host of a file on Computer #1. Or perhaps the dude who uses Computer #1 comes back from lunch and double-clicks the local file. It's already open — by you. So now the computer that physically holds the file becomes a guest of you, the remote host of a file residing back on Computer #1. FileMaker is very network-intensive. Chatty. Constant communication between guest and host. Constant flushing of guest cache to host cache, and of host cache to hard disk. Constant new reads of data on hard disk into host cache. You really don't want to know what a snarled-up mess the packet-path ends up looking like in a case like this. Drop a few packets and say hello to file corruption. The method I outlined is a PITA to set up but should be quite fast once set up: you double-click the local file, it opens in FileMaker, opens the real file over the network for you (always as a guest, using appropriate guest protocol), and then closes itself. It should not be any slower than double-clicking an alias to the file. It should, in fact, be faster.