>>>Where using Novell 5 with about 30 machines, we seem to be getting not a dabase file errors a few times a week. This can be a pain since the filefix program we're using doesn't always solve the problem.
>>>
>>>Could this be down to a few select machines, how can I track them down?
>>>
>>>Sometimes smoe of the faster machines seem to hang when doing SQL, could this be connected.
>>
>>I've had some experience like that seven years ago with Novell 4.01, and switching the compression for tables (and memos and indexes) helped, but generally the problems went away with 4.02.
>>
>>Currently I was doing something that instantiated lots of objects in design mode and destroyed them right away, so I had C0000005s about once in 20 minutes or so. The trick I applied was to open the tables involved AGAIN, go to the last record, replace some field with something else, tableupdate, restore the field, tableupdate again, close. Invariably I had the tables with the last saved record intact, no matter how it crashed.
>>
>>Now this may slow down your operation, but it seems to be a sure way to have tables in good condition. It should work in 2.6 as well, it has Use Again. It's just a matter of when will you do this, i.e. how often. Of course, no tableupdate - a Flush would do.
>
>
>Hmm, is this some smart solution for anyone having these kind of problems ??
>Dragan, what you, in fact, say, is that when you have one PC somewhere in a corner, always having all tables open, and when some PC crashes let that PC do what you described (for all tables, or just the ones recognized to be corrupted).
>That it needs 4 PC's for 1,000 tables is something else, but why not.

I actually noticed this in FPD2.6 or even 2.0, on bad local networks or when one station would hang, it helped if we opened the same form (OK, screen :) on another machine, do some pro-forma editing (like adding a dot in a text field somewhere) and closed the form. Then we could reboot the stuck station and the tables were OK. I developed a private theory that it's the server side buffers which don't get flushed properly unless the server is told to do so - and it won't be told by a stuck workstation, but it can be told by another one. In the next iteration, I've come to this solution of opening the same tables twice, and doing this sort of forced flushing periodically. Worked so far, but I didn't have such a nasty environment at hand to give it a heavy duty test.

I'm marking this thread, hoping that others will try this out and in the end we may be somewhat wiser about all this.