> Call the TDBISAMTable and/or TDBISAMQuery FlushBuffers method after any
Post
> or Delete operation.  That will ensure that the data is flushed to the
hard
> drive via the OS after any modifications and should cut down on incidences
> of corruption.

Which differenze : Session.StrictChangeDetection  and FlushBuffers  ?

Antony,

<< Is there a global method , only one for all my application ( for all
TDBISAMTable  ) ? >>

Yes, but it can slow down performance in some cases so you'll have to try it
and see if the performance is acceptable:

http://www.elevatesoft.com/dbisam4d5_tdbisamsession_forcebufferflush.htm

--
Tim Young
Elevate Software
www.elevatesoft.com

Jan,

<< Also make sure to tell your client that their employees should not start
a database operation (Insert, Update, etc.) and then walk away
from their computer, leaving the record "dirty". There's much more of a
chance of corruption if the record is "dirty". >>

Actually, that all takes place in memory so it won't hurt anything.  It's
after the write occurs to the OS and the OS continues to keep the dirty data
in its file system buffers that there's an issue.  That's why the OS
flushing solves the issue in most cases - it prevents the OS from caching
the dirty data too long and possibly losing it in a crash.

--
Tim Young
Elevate Software
www.elevatesoft.com

Antony,

<< Which differenze : Session.StrictChangeDetection  and FlushBuffers  ? >>

The two are completely different - StrictChangeDetection has to do with
change detection with multiple sessions/users.  See my other message on the
ForceBufferFlush property. That's the property that you want.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for the information Tim. I learn something new everyday.

--
Regards,
Jan Ferguson


Tim Young [Elevate Software] wrote:

> Jan,
>
> << Also make sure to tell your client that their employees should not
> start a database operation (Insert, Update, etc.) and then walk away
> from their computer, leaving the record "dirty". There's much more of
> a chance of corruption if the record is "dirty". >>
>
> Actually, that all takes place in memory so it won't hurt anything.
> It's after the write occurs to the OS and the OS continues to keep
> the dirty data in its file system buffers that there's an issue.
> That's why the OS flushing solves the issue in most cases - it
> prevents the OS from caching the dirty data too long and possibly
> losing it in a crash.

Tim

Antony Miller wrote:

> My application is very big..... and complex.
> This hint is too expensive and too long like work.


I assume you mean expensive in time because the component5 are included
with Delphi at no additional cost.  Only you can decide if the problem
is critical enough to justify the labor to fix it.

Tim

Could you explain why Session.ForceBufferFlush is slower than
Table.ForceBufferFlush ? I have inherited TDBISamTable and TDBISAMQuery and
I can easly change the setting from Session and put ForceBufferFlush just
after the Post and Delete.

Eduardo

Eduardo,

<< Could you explain why Session.ForceBufferFlush is slower than
Table.ForceBufferFlush ? I have inherited TDBISamTable and TDBISAMQuery and
I can easly change the setting from Session and put ForceBufferFlush just
after the Post and Delete.>>

In that case there is no difference.  What I was referring to is a case
where you have something like this:

Table1.Edit;
// Update
Table1.Post;

Table1.Edit;
// Update
Table1.Post;

Table1.Edit;
// Update
Table1.Post;

In such a case, it would be faster to use:

Table1.Edit;
// Update
Table1.Post;

Table1.Edit;
// Update
Table1.Post;

Table1.Edit;
// Update
Table1.Post;

Table1.FlushBuffers;

than it would be to use the TDBISAMSession.ForceBufferFlush:=True construct.
The simple reason being that ForceBufferFlush would cause 3 flushes to disk
instead of one.  This becomes more and more critical as the number of Posts
to the same table increases.   However, you could just as easily use a
simple transaction around the above to get the same desired result with even
more speed.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

Ok, got it.

Thanks