I have a client who is running FM server over a WAN. Guests are opening the files via the "Host" button.

Their network tends to drop out periodically and it seems to be causing files to corrupt. At this point it is a daily occurrence.

Anyone know why this is happening?

What do you mean by "seems to be causing the files to corrupt"? Are the databases definitely getting trashed? I ask this because on all the FM Server setups I've administered, having a client drop off the network suddenly (OS crash, power failure, cable getting yanked, etc.) I've never had this effect the files on the server.

Network loss over a WAN can be caused by a load of things, and is outside the scope here, but I'd be interested to hear if anyone else has come across db corruption due to a simple client drop-out.

-Stanley

My experience is that a user disconnected from a database on a network, is in fact........just disconnected. The database is still open and not closed improperly and should not become corrupt. The computer hosting the files must be shutting down without warning(by user...by backup procedure?:?). Hope this helps.

Michael

That is what I would expect.

Unfortuantely, I am in another state and I am getting all the information second hand. What I have been told is that when they try to open the files after their network goes down, they get a FM message that the files have been damaged.

Does not sound like the client is dropping, but that the server is dropping.

What is happening on the server?

The biggest advantage of FMP on Terminal Server apart of incredible speed is data consistency. Even if connection is lost, nothing at all happen :

Despite the assertion that "nothing at all happen" it does happen. It is not as rare as some people may believe, but when any system that is communicating has that communication dropped unexpectedly, or with a noise burst, you don't know what will happen.

Transactions are supposed to prevent this, but they are not 100% reliable either. With electrons flowing like water, who knows?

One thing I did with the remote clients is make them go thru a buffer file first. That way if their connection drops only the buffer gets corrupted (if that).

I found the problem seemed to crop up when 2 people are trying to access the same record and both are entering data and one drops. This is rare luckily and usually the only problem that came up was the db shutting down abnormally. So a restart of the db solved the problem. Oh, by rare I mean < 1 time per month.

I think what is happening is that the first client gets the lock on the record but when he drops unexpectedly the 2nd client grabs the lock even tho there has been partial data transmission by the first client. I've been meaning to play with the setting for when data is saved to see if that fixes the problem. Currently mine is set to "during any idle time".

RE: Despite the assertion that "nothing at all happen" it does happen.

Not with Terminal Services on Terminal Server. There isn't any connection between remote TS client and FM server. Period.

Even when FM client gets disconnected, nothing will usually happen but that is not 100% guaranty. It can be, that record is partially updated.

But structural damage to database can only happen, if the remote FM user was modifying fields or layouts.

I reckon that it's possible that network outages might cause file corruption.

But it's not a FMS problem, it's a network problem. The only way to fix it is to fix the network.

Sure. Garbage in garbage out. That I saw few times.

Technically you are right that it is not an FM problem. However, files can get corrupted due to problems with the network. It is just that you can't do anything with FM to fix the problem, other than buffering.

A good example of this was the brown out we had a while back. This was not the fault of FM but files were corrupted. We also had corrupted files on SQL Server and Access.

Corrupted files should not happen when we use transactions, but they do. I bet I could corrupt files using TS too if I really tried.

Brown-outs are solved with uninterruptable power supplies, or at least some sort of power filter thing. I'd have though that a UPS was a given for any production server.

I've personally seen a FM Server (v3) that sat on a network for 2 years without any restarts or file corruption whatsoever (on a blue+white G3) even though the network had its fair share of problems over the period. It was on a UPS that probably provided some filtering, but when I tested it properly (by pulling out the plug) the machine went down instantly!

DonH wrote: "I've been meaning to play with the setting for when data is saved to see if that fixes the problem. Currently mine is set to "during any idle time"."

Probably what you should try is using the "Flush Cache to Disk" script step after every transaction. This forches FMP to write back to the file at that instant. It could have the potential, on a slow network, to significantly affect performance though.

RE: I've personally seen a FM Server (v3) that sat on a network for 2 years without any restarts or file corruption

We are usually restarting FM Server machine every 6-12 months. In 6 years we experienced single small corruption on location with very old and quirky power supply. The power was out there every week or so. We've just restored last backup. In my 21-year experience, FMS is number one robust and reliable application/service.

In another words, to have maintenance expenses around $50-100 for 3 FM servers during 6 years is just amazing!