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

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 (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


nmm wrote:

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 (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


nmm wrote:

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 (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Next Pervasive Service & Support Class - Nov 2008 ***


nmm wrote:

Hi Bill,

thanx for that information: its calming to know!

Regards
Mircea

BtrieveBill schrieb:

Hi Bill,

thanx for that information: its calming to know!

Regards
Mircea

BtrieveBill schrieb:

Hi Bill,

thanx for that information: its calming to know!

Regards
Mircea

BtrieveBill schrieb: