Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 19 of 19 total |
electric power fall : Every time database corrupt ! |
Tue, Feb 28 2006 5:51 AM | Permanent Link |
"Antony Miller" | > 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 ? |
Tue, Feb 28 2006 8:41 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Feb 28 2006 8:43 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, Feb 28 2006 8:44 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, Feb 28 2006 4:18 PM | Permanent Link |
"J. B. Ferguson" | 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 |
Tue, Feb 28 2006 7:45 PM | Permanent Link |
"David Farrell-Garcia" | 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. |
Wed, Mar 1 2006 4:50 AM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Wed, Mar 1 2006 10:43 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, Mar 1 2006 12:02 PM | Permanent Link |
"Jose Eduardo Helminsky" | Tim
Ok, got it. Thanks |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, May 23, 2024 at 07:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |