Re: btrieve caching
- From: BtrieveBill <billbach@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 06 Nov 2008 10:00:59 -0600
The database engine can use multiple levels of cache. In addition to the internal L1 database cache (Cache Allocation=#), the system can also leverage the operating system cache (Use System Cache=Yes). One of these is holding onto the "old" data for you.
In a Windows environment, the system does NOT always re-read data after the files have been physically replaced at the OS level, and some level of reading of the cached data is expected. This is simply beyond the design of the environment.
The easiest solution is to stop and restart the engine whenever you must play with files at the OS level. In our data recovery work, where we often work with the files at the OS level, we run into this all the time. We simply rename the file to a new name to "clear" the data from cache.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@xxxxxxxxxxxxxxxxxxxx
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***
nmm wrote:
Hi,.
using Pervasiv 8.x wie observed the following strange behavior:
the engine runs an a server A with Windows 2003, the clients are
WinXPpro SP2.
In the PSQL-Control-Center on all clients the option "local cache
engine" is set to "OFF".
All data-access is performed via btrieve.
Now we have a btrieve-file, say bbb.dat. The file is closed (not
listed in the PSQL-Monitor on A). We copy bbb.dat to an other system
(using a single seat engine) an change say the record with autoinc-Nr.
3 (calling that simply record 3).
Than we ha a modified version of bbb.exe, which we call the "remote"
bbb.dat. We call this "remote" cahnge "R".
If one now opens the original bbb.dat in the server/client environment
and change also record Nr. 3, but make a different change as in the
"remote" bbb.dat. We call this cahnge "B".
Then close bbb.dat on the client (its again not listed in the Monitor
from the server A).
Now copy the remotely changed bbb.dat to the server A, overwriting the
existing bbb.dat at BS-level. At BS-level the bbb.dat now is identical
to the "remote" bbb.dat (byte-to-byte compare!).
If you now open the bbb.dat from a client (in the client-server
environment) an show record 3: so you will not see that version of
that record from the remote bbb.dat("R") but you get still the content
from change "B"!! The physical file contanins definitely change "R",
but the engine shows change "B".
Now we end the session from that client (breive-stop-operation) and
open a new session: opening bbb.dat it again shows cahnge "B".
Now we erased the file bbb.dat from the server A completely and
recreate it via usual btrieve-operations. Close the new file and end
btreive-sesseion. Restart the session an open bbb.dat: it is empty!
Close bbb.dat. Than again overwrite this new emtpy-file with the
remote bbb.dat at BS-level. If you now open that bbb.dat it again
shows change "B"!
(even if you open bbb.dat from a different client, it shows change "B"
not "R".)
We do this also without longer breaks (we dont wait after overwriting
bbb.dat, just start a new session and open bbb.dat and so on)
Than we finaly restarted the btrieve-engine on the server A and now at
long last we get change "R" if we open bbb.dat (as expected long before).
What may the reason for this? There seem something wrong with the
caching on the server! Is this a known issue?
Regards
M. Malarski
- Follow-Ups:
- Re: btrieve caching
- From: nmm
- Re: btrieve caching
- References:
- btrieve caching
- From: nmm
- btrieve caching
- Prev by Date: btrieve caching
- Next by Date: Re: btrieve caching
- Previous by thread: btrieve caching
- Next by thread: Re: btrieve caching
- Index(es):
Relevant Pages
|