User forced to close connection

[vasilek]

Hello. We have FMS5.5/Win2000Server and 10 users on FMP6/WinXP. They all open files via Host. The files on FMS get damaged quite often. When I look in log of FMS I see the message: "usersname forced to close connection".

Does anyone know why it is happening? Is the user forced its FMP to close connection or FMS forced the user? How to prevent this from happenning again?

Many thanks!

[stanley]

Vasilek:

Isn't that when someone using the Server Admin plugin kicks people off of files? Or when you do it directly from the Server (if you have that ability)?

-Stanley

[vasilek]

There is no one I know using Remote Server Administration. In addition, I found another error related to file damaging: "Closing file due to serious error (10207)".

I am trying to figure out whether the users closing the connection (may be due to computer crash) ort something happens to the file during work so FMS is closing the file for hosting?

[DykstrL]

I think what you're trying to diagnose is backwards. The clients are being booted off the hosted files because the files are corrupt.

Files hosted on FM Server can't get corrupted by how the client logs off, closes the file, or pulls the plug (except for a very few exceptions). That's what the server does - it protect the files from errant client snafus.

Corrupt files on a server will force clients to be disconnected, or even the server to stop or freeze and even possibly lock up the hardware.

If you shutdown the server without going through the Remote Server Administration and closing each folder/file first, you risk causing corruption to your files. A normal shutdown will stop the FMS service, but will not allow enough time for the FMS service to properly disconnect clients (2 minutes if connected) and close the file - Windows will force the service to stop when it times out, which it will if the server is disconnecting clients and closing the files. If clients are connected, corruption WILL occur.

You need to run Recover on the errant files, export just the data from the recovered files, and import the data into a new fresh backup clone of the file.

[NYPoke]

"Files hosted on FM Server can't get corrupted by how the client logs off, closes the file, or pulls the plug (except for a very few exceptions). That's what the server does - it protect the files from errant client snafus."

That is the Official Company Line, but its the few exceptions that seem to be the problem.

We are having similar problems. We have had a couple bad instances, plus some ongoing problems.

In one instance, FM Server (5.5) shut down one of our 200+ files on its own. We did nothing to it. It certainly appears that it was related to a high workload (I added some Summary & Calculation fields that really stressed out our Terminal Server Clients). Naturally, everybody got disconnected from that file.

A couple hours later, it happened again, but this time the file was corrupted. I can only assume it was corrupted the first time, but we didn't catch it until the second.

But now (& prior to the above), we have users disconnected several times a day - without FM Server stopping anything.

I was reading the Lost Hosts Thread. Appears this problem might be related, in that our Network Admin is now looking at hubs & routers, after reviewing the log closely.

Good Luck guys. I'll post if we figure anything out.

[DykstrL]

One of the ways I know that a file can get corrupted on the server is a client loses connection in the middle of a large import - it usually corrupts more records than FM can handle.

Another certain way to corrupt a file is defining fields and the client gets booted - especially a crash, before the file has a chance to save all of the field changes and recalculates all of the records.

In your response you mentioned Terminal Server clients, which wasn't mentioned in your original post. If all of your clients are using Terminal Server to connect to the FM server and Terminal server goes down, all of the connections are lost all at once, which could very well cause a whole lot of data corruption - maybe more than FM can handle. I'm not a Terminal Server expert, but from what I do know, it is a little different animal.

In any event, you now have to deal with the corruption of the server files. If not, the problem will not go away and will get progressively worse. You need to go back to a good, clean, uncorrupted clone and import the records.

[NYPoke]

Yes, we did get rid of the corrupt file. We went to a backup from 2 hours earlier. Back in business from that standpoint.

Now, we just have users getting "Connection to Host Lost". Usually happens around backup time. The Server (version 5.5) seems fine & our files are intact.

We have added quite a few people to the Terminal Server in the past few weeks, but we are not yet sure if that has anything to do with it. Some of our non-Terminal Server people have gotten disconnected as well. We want to keep on eye on this, just in case it is a symptom of something serious.

My understanding is that the FM Client (version 6) should not time out during backups. I am still learning about how the Client & Server communicate though.

[DykstrL]

You may not get disconnected from the server during backups and cache flushes from the server side, but it is possible that the client machine is detecting the non-response on the connection and stopping that connection. All but the cheapest NIC cards have the ability to extend the timeout for connections. Maybe set the timeout to a little longer duration and see what happens.

[chrisho30]

We also have force close file problem and got serious error code 10207.

We hosted 38 FMP5 files on a FMP5 server on Windows NT platform. Only one of the file also got corrupt which has 70,000/+ records. We did not use Admin plug-in to force closed the file or restart the FMP5 server durign office hours. The problem usually happen when the user typing (or copy-and-paste) information into this file. I use FMP recovery tool but the successful percentage is almost 0%.

I check the FMP Knowledge database, it seems the problem found in FMP version 3, it said 10207 error is due to user did a find request and then edit a large text field in found set. I think it may be the problem. But we really need a large text field to keep track of our order progress. Is there any solution to solve it? Does version 7 fixed this problem?

[chrisho30]

We also have force close file problem and got serious error code 10207.

We hosted 38 FMP5 files on a FMP5 server on Windows NT platform. Only one of the file also got corrupt which has 70,000/+ records. We did not use Admin plug-in to force closed the file or restart the FMP5 server durign office hours. The problem usually happen when the user typing (or copy-and-paste) information into this file. I use FMP recovery tool but the successful percentage is almost 0%.

I check the FMP Knowledge database, it seems the problem found in FMP version 3, it said 10207 error is due to user did a find request and then edit a large text field in found set. I think it may be the problem. But we really need a large text field to keep track of our order progress. Is there any solution to solve it? Does version 7 fixed this problem?

[chrisho30]

We also have force close file problem and got serious error code 10207.

We hosted 38 FMP5 files on a FMP5 server on Windows NT platform. Only one of the file also got corrupt which has 70,000/+ records. We did not use Admin plug-in to force closed the file or restart the FMP5 server durign office hours. The problem usually happen when the user typing (or copy-and-paste) information into this file. I use FMP recovery tool but the successful percentage is almost 0%.

I check the FMP Knowledge database, it seems the problem found in FMP version 3, it said 10207 error is due to user did a find request and then edit a large text field in found set. I think it may be the problem. But we really need a large text field to keep track of our order progress. Is there any solution to solve it? Does version 7 fixed this problem?

[NYPoke]

Hey 10207, that's our baby. I thought I looked everywhere (apparently not) but never found anything on it. We had assumed it was a Microsoft problem.

We have 5.5 Server, so I can't speak for 7. I'll check some more on it, but we do have some cut&paste work going on from other programs. That could easily have been our corruption problem.

[NYPoke]

Hey 10207, that's our baby. I thought I looked everywhere (apparently not) but never found anything on it. We had assumed it was a Microsoft problem.

We have 5.5 Server, so I can't speak for 7. I'll check some more on it, but we do have some cut&paste work going on from other programs. That could easily have been our corruption problem.

[NYPoke]

Hey 10207, that's our baby. I thought I looked everywhere (apparently not) but never found anything on it. We had assumed it was a Microsoft problem.

We have 5.5 Server, so I can't speak for 7. I'll check some more on it, but we do have some cut&paste work going on from other programs. That could easily have been our corruption problem.

[chrisho30]

This is found at FileMaker Techinfo :

When a large number of guests perform a find and subsequently edit a large text field in the found set, all guests get disconnected. The FMSRVLOG.TXT file says that disconnected guests have encountered a 10207 error. Once all guests are disconnected from the file, the Server closes the file and logs the same error

If it is Window's program, it will also damage the others because we usually open at least 4 database file at the same time. However, only Log file corrupted. Therefore, I don't think it is Window's problem.

In a week before, I wrote a script and export current day Log record and manually run this script in every 30-60 minutes. I found if I run the script every working day the Log file will not be corrupt. If I forget run (or lazy and not to run) the script, the Log file will be corrupt in at 10:00am or 10:30am (we start work at 9:00am).

Script like this:

Enter Find Mode[]

Set Field("Last Update Date", "Today")

Perform Find

Export Records (Restore, No dialog, "backupfp5")

I would like to know is there any chance I only manually run the script at the morning, then it will periodically run in every 30/60 minutes? Thanks. [color:blue]

[chrisho30]

This is found at FileMaker Techinfo :

When a large number of guests perform a find and subsequently edit a large text field in the found set, all guests get disconnected. The FMSRVLOG.TXT file says that disconnected guests have encountered a 10207 error. Once all guests are disconnected from the file, the Server closes the file and logs the same error

If it is Window's program, it will also damage the others because we usually open at least 4 database file at the same time. However, only Log file corrupted. Therefore, I don't think it is Window's problem.

In a week before, I wrote a script and export current day Log record and manually run this script in every 30-60 minutes. I found if I run the script every working day the Log file will not be corrupt. If I forget run (or lazy and not to run) the script, the Log file will be corrupt in at 10:00am or 10:30am (we start work at 9:00am).

Script like this:

Enter Find Mode[]

Set Field("Last Update Date", "Today")

Perform Find

Export Records (Restore, No dialog, "backupfp5")

I would like to know is there any chance I only manually run the script at the morning, then it will periodically run in every 30/60 minutes? Thanks. [color:blue]

[chrisho30]

This is found at FileMaker Techinfo :

When a large number of guests perform a find and subsequently edit a large text field in the found set, all guests get disconnected. The FMSRVLOG.TXT file says that disconnected guests have encountered a 10207 error. Once all guests are disconnected from the file, the Server closes the file and logs the same error

If it is Window's program, it will also damage the others because we usually open at least 4 database file at the same time. However, only Log file corrupted. Therefore, I don't think it is Window's problem.

In a week before, I wrote a script and export current day Log record and manually run this script in every 30-60 minutes. I found if I run the script every working day the Log file will not be corrupt. If I forget run (or lazy and not to run) the script, the Log file will be corrupt in at 10:00am or 10:30am (we start work at 9:00am).

Script like this:

Enter Find Mode[]

Set Field("Last Update Date", "Today")

Perform Find

Export Records (Restore, No dialog, "backupfp5")

I would like to know is there any chance I only manually run the script at the morning, then it will periodically run in every 30/60 minutes? Thanks. [color:blue]

[NYPoke]

Chris, I have more of a background in Oracle, Informix & SQL Server, so my year or so in FileMaker is kind of limited. But, from a general Database Standpoint, my advise would be to run your Log, once at the beginning of the day, about 45-60 minutes during Non-Peak hours and about 20-30 minutes during Peak hours, then once at the end of the day.

With FileMaker, you have to be careful though. During Peak hours, you don't want to stress out the Server too much (especially FM 6 & prior, not sure about 7).

I do like this approach though. We perform a traditional FM Backup 6 times a day. We are at a point where its taking too long (4-5 minutes), slowing down the users and taking too much disk space. Plus, our connection problems seem to related to our back-ups.

Your approach is closer to the Oracle/Informix method of taking a backup & logging transactions. I'll talk to the boss about trying this. You just might have helped us out.

Only catch with this is that the Users could be partially through updating related records, leaving some data inconsistancy. I think that is always a concern with FileMaker 6 & before though. We usually have to redo a couple records when we go to backup file.

You can purchase Plug-Ins to Schedule the scripts. At least I think I saw some scheduling Plug-Ins. That would automate your processes & take out the forgetfullness problem. In your case, it should be a good investment.

[NYPoke]

Chris, I have more of a background in Oracle, Informix & SQL Server, so my year or so in FileMaker is kind of limited. But, from a general Database Standpoint, my advise would be to run your Log, once at the beginning of the day, about 45-60 minutes during Non-Peak hours and about 20-30 minutes during Peak hours, then once at the end of the day.

With FileMaker, you have to be careful though. During Peak hours, you don't want to stress out the Server too much (especially FM 6 & prior, not sure about 7).

I do like this approach though. We perform a traditional FM Backup 6 times a day. We are at a point where its taking too long (4-5 minutes), slowing down the users and taking too much disk space. Plus, our connection problems seem to related to our back-ups.

Your approach is closer to the Oracle/Informix method of taking a backup & logging transactions. I'll talk to the boss about trying this. You just might have helped us out.

Only catch with this is that the Users could be partially through updating related records, leaving some data inconsistancy. I think that is always a concern with FileMaker 6 & before though. We usually have to redo a couple records when we go to backup file.

You can purchase Plug-Ins to Schedule the scripts. At least I think I saw some scheduling Plug-Ins. That would automate your processes & take out the forgetfullness problem. In your case, it should be a good investment.

[NYPoke]

Chris, I have more of a background in Oracle, Informix & SQL Server, so my year or so in FileMaker is kind of limited. But, from a general Database Standpoint, my advise would be to run your Log, once at the beginning of the day, about 45-60 minutes during Non-Peak hours and about 20-30 minutes during Peak hours, then once at the end of the day.

With FileMaker, you have to be careful though. During Peak hours, you don't want to stress out the Server too much (especially FM 6 & prior, not sure about 7).

I do like this approach though. We perform a traditional FM Backup 6 times a day. We are at a point where its taking too long (4-5 minutes), slowing down the users and taking too much disk space. Plus, our connection problems seem to related to our back-ups.

Your approach is closer to the Oracle/Informix method of taking a backup & logging transactions. I'll talk to the boss about trying this. You just might have helped us out.

Only catch with this is that the Users could be partially through updating related records, leaving some data inconsistancy. I think that is always a concern with FileMaker 6 & before though. We usually have to redo a couple records when we go to backup file.

You can purchase Plug-Ins to Schedule the scripts. At least I think I saw some scheduling Plug-Ins. That would automate your processes & take out the forgetfullness problem. In your case, it should be a good investment.

[chrisho30]

NYPoke, sorry to let you know my Log database corrupted in 7 minute later after we start working.

I'm interest to know how you can do 6 times backup per day? Is there anyway to pause the database to do backup? I try it before but it usually make FMP server closed the database (but without damage the Log database).

Do you ever (base on this problem) phone Filemaker and get their advise? By the way, what version of FMP you're using?

[chrisho30]

NYPoke, sorry to let you know my Log database corrupted in 7 minute later after we start working.

I'm interest to know how you can do 6 times backup per day? Is there anyway to pause the database to do backup? I try it before but it usually make FMP server closed the database (but without damage the Log database).

Do you ever (base on this problem) phone Filemaker and get their advise? By the way, what version of FMP you're using?

[chrisho30]

NYPoke, sorry to let you know my Log database corrupted in 7 minute later after we start working.

I'm interest to know how you can do 6 times backup per day? Is there anyway to pause the database to do backup? I try it before but it usually make FMP server closed the database (but without damage the Log database).

Do you ever (base on this problem) phone Filemaker and get their advise? By the way, what version of FMP you're using?

[stanley]

NYPoke & Chrisho30:

Using the Server's Scheduled Backup feature in FMS 5 will indeed slow things to a crawl, and I agree that it can cause disconnects if people still try to hit the server hard (ignoring that their mouse pointer has changed into a cup of coffee, which is a training issue.) I tend to only backup when I know there are slack times in the daily schedule - lunch time and the morning & afternoon coffee breaks, and definitely not when the system is in heavy use. I think six times a day is a bit much, but given your experiences, I understand the intensity of the schedule.

However, I think that both NYPoke and Chrisho30 are encountering files that are corrupt before they even show signs of it. I think you've got to track way back and find the oldest version of the files you can find, or even rebuild the files from scratch (if possible.) The reason is that files can become corrupt and continue to work for quite a while before the corruption becomes fatal (or so bad that FileMaker detects the corruption and closes or refuses to open the file.)

I recently had a file blow up in a system about seven months after I last did any modification to it; I went back to a copy from a year ago (before I arrived on the scene) and flogged the file with data until it announced that it was corrupt. The previous developer had already left me with two files that went corrupt after some delay. Now it's three. I have a feeling there are more, as the only files on the system which have become corrupt are the ones which existed before I came along to finish the work of the other "developer."

-Stanley

[stanley]

NYPoke & Chrisho30:

Using the Server's Scheduled Backup feature in FMS 5 will indeed slow things to a crawl, and I agree that it can cause disconnects if people still try to hit the server hard (ignoring that their mouse pointer has changed into a cup of coffee, which is a training issue.) I tend to only backup when I know there are slack times in the daily schedule - lunch time and the morning & afternoon coffee breaks, and definitely not when the system is in heavy use. I think six times a day is a bit much, but given your experiences, I understand the intensity of the schedule.

However, I think that both NYPoke and Chrisho30 are encountering files that are corrupt before they even show signs of it. I think you've got to track way back and find the oldest version of the files you can find, or even rebuild the files from scratch (if possible.) The reason is that files can become corrupt and continue to work for quite a while before the corruption becomes fatal (or so bad that FileMaker detects the corruption and closes or refuses to open the file.)

I recently had a file blow up in a system about seven months after I last did any modification to it; I went back to a copy from a year ago (before I arrived on the scene) and flogged the file with data until it announced that it was corrupt. The previous developer had already left me with two files that went corrupt after some delay. Now it's three. I have a feeling there are more, as the only files on the system which have become corrupt are the ones which existed before I came along to finish the work of the other "developer."

-Stanley

[stanley]

NYPoke & Chrisho30:

Using the Server's Scheduled Backup feature in FMS 5 will indeed slow things to a crawl, and I agree that it can cause disconnects if people still try to hit the server hard (ignoring that their mouse pointer has changed into a cup of coffee, which is a training issue.) I tend to only backup when I know there are slack times in the daily schedule - lunch time and the morning & afternoon coffee breaks, and definitely not when the system is in heavy use. I think six times a day is a bit much, but given your experiences, I understand the intensity of the schedule.

However, I think that both NYPoke and Chrisho30 are encountering files that are corrupt before they even show signs of it. I think you've got to track way back and find the oldest version of the files you can find, or even rebuild the files from scratch (if possible.) The reason is that files can become corrupt and continue to work for quite a while before the corruption becomes fatal (or so bad that FileMaker detects the corruption and closes or refuses to open the file.)

I recently had a file blow up in a system about seven months after I last did any modification to it; I went back to a copy from a year ago (before I arrived on the scene) and flogged the file with data until it announced that it was corrupt. The previous developer had already left me with two files that went corrupt after some delay. Now it's three. I have a feeling there are more, as the only files on the system which have become corrupt are the ones which existed before I came along to finish the work of the other "developer."

-Stanley

[NYPoke]

"I'm interest to know how you can do 6 times backup per day? Is there anyway to pause the database to do backup? I try it before but it usually make FMP server closed the database (but without damage the Log database)."

Like Stanley said: We let the Server Scheduling do the backups. Wouldn't try to do it manually. And like he said, it slows things to a crawl. BUT, it does reduce the chance of corruption. I agree that the corruption might have already happened & the backup brought it to our attention.

We HAVE to back up 5 or 6 times a day. With 13 offices in 8 states, we can't go too far back to reprocess the data entry. (I'ld rather not be using FileMaker, but its a Management decision.)

I did an experiment on just exporting the data. But we have so many Calculations & Summaries, it takes way too much CPU & RAM. Transaction logging would be wonderful, just not going to make it work in 5.5/6. Nice idea though.

"Do you ever (base on this problem) phone Filemaker and get their advise? By the way, what version of FMP you're using? "

I never call FileMaker. They don't sound very useful.

We have FM 5.5 on the Server & FM 6 for the clients.

[NYPoke]

"I'm interest to know how you can do 6 times backup per day? Is there anyway to pause the database to do backup? I try it before but it usually make FMP server closed the database (but without damage the Log database)."

Like Stanley said: We let the Server Scheduling do the backups. Wouldn't try to do it manually. And like he said, it slows things to a crawl. BUT, it does reduce the chance of corruption. I agree that the corruption might have already happened & the backup brought it to our attention.

We HAVE to back up 5 or 6 times a day. With 13 offices in 8 states, we can't go too far back to reprocess the data entry. (I'ld rather not be using FileMaker, but its a Management decision.)

I did an experiment on just exporting the data. But we have so many Calculations & Summaries, it takes way too much CPU & RAM. Transaction logging would be wonderful, just not going to make it work in 5.5/6. Nice idea though.

"Do you ever (base on this problem) phone Filemaker and get their advise? By the way, what version of FMP you're using? "

I never call FileMaker. They don't sound very useful.

We have FM 5.5 on the Server & FM 6 for the clients.

[NYPoke]

"I'm interest to know how you can do 6 times backup per day? Is there anyway to pause the database to do backup? I try it before but it usually make FMP server closed the database (but without damage the Log database)."

Like Stanley said: We let the Server Scheduling do the backups. Wouldn't try to do it manually. And like he said, it slows things to a crawl. BUT, it does reduce the chance of corruption. I agree that the corruption might have already happened & the backup brought it to our attention.

We HAVE to back up 5 or 6 times a day. With 13 offices in 8 states, we can't go too far back to reprocess the data entry. (I'ld rather not be using FileMaker, but its a Management decision.)

I did an experiment on just exporting the data. But we have so many Calculations & Summaries, it takes way too much CPU & RAM. Transaction logging would be wonderful, just not going to make it work in 5.5/6. Nice idea though.

"Do you ever (base on this problem) phone Filemaker and get their advise? By the way, what version of FMP you're using? "

I never call FileMaker. They don't sound very useful.

We have FM 5.5 on the Server & FM 6 for the clients.

[NYPoke]

5/5/2005...

Well, we our Server (5.5) has crashed twice this week, and the owner is more or less pissed off. We built a new physical server & moved to it yesterday - nothing but FileMaker running. It went down about 30 minutes ago.

Always goes down during backup, and may have something to do with some large Accounting processes - which have to get done.

I'm going for a new plan of action here. I'm going to suggest we back up, with the standard Server backup, once in the mornings & do Clones during the day - on a different machine.

Hopefully, this is a good idea. Input always welcome.

[stanley]

NYPoke:

There's something seriously wrong for your server to crash that often, but there are so many possibilities, I can't help there. However, I was curious to see your new plan - I understand your morning backup, but why the clones during the day? A clone has no data in it, so it's not a backup at all...

If you watch your server closely, you may be able to figure out exactly where the crash is occuring. One option is to set up a new backup schedule for each file in the solution; because they're not being backed up together, related data will possibly be a mess, but you'll be able to see which items are getting backed up and which are failing, and at least be able to identify if a specific file is the culprit. If you do this, make sure to stagger the backup times so that the server has time to finish with a file before the next backup begins.

-Stanley

[NYPoke]

Sorry, I mis-typed there. Not a clone. Was thinking of Save Copy As (you can save the data that way I believe?). Either way, the boss decided to backup at 6:00 AM & around 10:00 PM. We are going to shut down the FM Server twice during the day & back up while FM Server is down.

Didn't want to bring down the whole company that way, but it is better than the crashing.

We have been monitoring the Server. It seems to be related to some heavy script processing that we do, during backups. The scripts can take 15-30 minutes sometimes. Now way around them.

We tried to keep the scripts from running during backups, but eventually somebody forgets (like me). By forcing FM Server down, we can make sure everything & everybody is out before backing up.

Thanks for the suggestion on the backup schedules. We have been able to tell where/when the crash occurs. Each time, one file is corrupt. We restore a previous backup. But as to which file is corrupt, it changes each time.

I am pretty sure the FM Server hits a problem & shuts itself down. Which ever file is being backed up, at that point, becomes corrupt.

Hopefully, taking Server offline, during the back up, will take care of the problem. If I don't post about another crash - it worked.