>> Trying to think of reasons why would anyone want to have it OFF is to get an error when more than a single record per buffered table is written to... if that's possible at all. I know any attempt at table buffering bangs when it's off. Maybe whoever wrote that app never got to the lesson when you do table buffering?
>
>
>Hi Dragan,
>Yeah everything is old school (RLOCK, FLUSH, etc.). I turned it on and everything SEEMS to be working but still not sure what might be broke now.

Thinking further... just check any situation where there may be more than one record written to a table - the existing system was supposed to save each record immediately or to work without buffering, in a straight-to-disk FPD manner. With multilocks off, it should be impossible to have table buffering, so it would either work unbuffered or would automatically save - having record buffering implies =tableupdate() whenever recno() changes. These wouldn't be implied where you have table buffering, so some of it may not be written to disk until you either explicitly call tableupdate() with appropriate parameters (1 as first, IIRC). If you never set buffering to 4 or 5, then it shouldn't be any different.