Board index » delphi » Delphi and Windows 95 Cache - Problems - Please Help!

Delphi and Windows 95 Cache - Problems - Please Help!

Hello all. Here's our problem.  Using Paradox 5 tables.  Cached
Updates is on.  We commit and apply (or whatever) the new
data/changes.  If you look at the tables, the data is there.  

Ok, now, at some point in time, the application locks-up.  You turn
off the computer and turn it back on, and all the data is now
"missing" from the tables (despite the fact that the data was commited
to the tables).  My project manager's guess is that it's got something
to do with the Windows 95 caching mechanism, and he wants to do an API
call to flush the cache (I'd rather not).  

Has anyone out there experienced this "problem", and if so, what was
your solution.  

Thanks.
D.

 

Re:Delphi and Windows 95 Cache - Problems - Please Help!


I've noticed the cache problem with Win95.  My suggestion is to use
database engine calls to write changes as they occur.  the following is a
tech note on windows bufferring and helpful dbi calls, dbiSaveChanges has
worked for me, hope this helps:

 PRODUCT  :  Delphi                                 NUMBER  :  2953
  VERSION  :  All
       OS  :  Windows/Win32
     DATE  :  February 8, 1996

    TITLE  :  BDE:  Writing Buffer to Disk

General:
=======

Changes made to a table are not written directly to disk until
the table is closed.  A power failure or system crash can
result in a loss of data, and an inconvenience.  To avoid this
loss of data, two direct Database Engine calls can be made,
both of which have the similar effects. These functions are
DbiUseIdleTime and DbiSaveChanges.

DbiSaveChanges(hDBICur):
=======================

DbiSaveChanges saves to disk all the updates that are in the
buffer of the table associated with the cursor (hDBICur). It

can be called at any point. For example, one may want to make
save changes to disk every time a record is updated (add
dbiProcs to uses clause):

procedure TForm1.Table1AfterPost(DataSet: TDataSet);
begin
  DbiSaveChanges(Table1.handle);
end;

This way, one does not have to worry about losing data if a
power failure or system crash occurs after a record update.

DbiSaveChanges can also be used to make a temporary table
(created by DbiCreateTempTable) permanent.

This function does NOT apply to SQL tables.

DbiUseIdleTime:
==============

DbiUseIdleTime can be called when the "Windows Message Queue"
is empty. It allows the Database Engine to save "dirty buffers"
to disk. In other words, it does what DbiSaveChanges does, but
performs the operation on ALL the tables that have been
updated. This operation however, will not necessarily occur
after every record update, because it can only be executed when
there is an idle period.

In Delphi, it can be used in this fashion (add dbiProcs to uses clause):

procedure TForm1.FormCreate(Sender: TObject);
begin
     Application.onIdle := UseIdle;

end;

procedure Tform1.UseIdle(Sender: TObject; var Done: Boolean);
begin
     DbiUseIdleTime;
end;

USAGE NOTES:
===========

Using both DbiUseIdleTime and DbiSaveChanges (after every
record modification) is redundant and will result in
unnecessary function calls. If the application is one that
perfroms a great deal of record insertions or modifications in
a small period of time, it is recommended that the client
either call DbiUseIdleTime during an idle period, or call
DbiSaveChanges after a group of updates.

If not very many updates are being performed on the table, the
client may choose to call DbiSaveChanges after every post or
set up a timer and call DbiUseIdleTime when a timer even is generated.

DISCLAIMER: You have the right to use this technical information subject to
the terms of the No-Nonsense License Statement that you received with the
Borland product to which this information pertains.

Douglas Troy <dt...@drsoftware.com> wrote in article
<57fkra$...@camel1.mindspring.com>...

Quote
> Hello all. Here's our problem.  Using Paradox 5 tables.  Cached
> Updates is on.  We commit and apply (or whatever) the new
> data/changes.  If you look at the tables, the data is there.  

> Ok, now, at some point in time, the application locks-up.  You turn
> off the computer and turn it back on, and all the data is now
> "missing" from the tables (despite the fact that the data was commited
> to the tables).  My project manager's guess is that it's got something
> to do with the Windows 95 caching mechanism, and he wants to do an API
> call to flush the cache (I'd rather not).  

> Has anyone out there experienced this "problem", and if so, what was
> your solution.  

> Thanks.
> D.

Other Threads