btrieve caching

[Database Administrator]

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

[Database Administrator]

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@goldstarsoftware.com
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
>
>

[Database Administrator]

Hi Bill,

thanx for that information: its calming to know!

Regards
Mircea

BtrieveBill schrieb:
> 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@goldstarsoftware.com
> http://www.goldstarsoftware.com
> *** Next Pervasive Service & Support Class - Nov 2008 ***
>
>
> nmm wrote: