Hi again,

the old problm still occur:



given a datafile with two internal indices:
1. an autoinc-index
2. an index, which by it self has no unique keys: but we added the
autoinc-segewmnt, so its unique.

Now running a loop like:

i) set a value to the first segment of Index 2, set the autoinc zero.

ii) call: "Get Greater Than or Equal operation (9= B_GET_GE)" with
that index nr. 2 (or get_first)

iii) if dstatus<>0 goto vii)

iv) do something with the data, like count something (no update
operations!)

v) call "Get Next operation (6=B_GET_NEXT)"

vi) goto iii)

vii) show result


This runs OK, if there is no other activity on the serverengine. BUT:
if there are other clients online, and if they run updates on the
datafile in question, the get next in the loop not allways return the
"next" record but sometimes a record already seen! So the loop goes
thru several records twice.
(seemingly the "iterated" getnext occurs at most once during the loop
is running: up to now, we dont see this happns twice or more within
one loop; but if the loop runs again, it again may occur).

Unfortunaltey we could not determin, how exactly thiis will happen:
whilch records came twice is (for us) not predictable.
We observe 3 different cases:

assume, the records in the file are

ABCDEFGHIJKLMNOPQ

(each letter represent one record)

A) nextrec again returns the first record: in this case we get:
ABCDEFGABCDEFGHIJKLMNOPQ
^ ^<-normal continue

B) nextrec again returns the record just visited:
ABCDEFGGHIJKLMNOPQ
^^

C) nextrec again returns an earlier record:
ABCDEFGHIJKGHIJKLMNOPQ
^ ^<-normal continue

D) normal operation:
ABCDEFGHIJKLMNOPQ

We observed that there seemingly in case C) never more then about 16
records are doubbled, while case A) may yield to a complete doubbling.





The updates coming from diferen clients dont concern records, that
will read by the loop: there where only records updated(or added) with
different key in the first segemtn of the index 2.

(The problm does not occur using workgroupengine.)

The questions are:
-what can we do to avoid this phenomen?
-is this issue solved ion V10.x? (for which x?).

Does anybody know this and can give hints?

We are quite sure, that this is no error in our application: we
checked it again and again.
It does also not concern the actual server/clientplatform, because we
observed it in several different environments.

I have send this as a "Pervasive Defect Submission" to pervasive.

Regards
M. Malarski

Now we observed the phaenomen also in PSQL Version 10.10.

An additional question:

is there a minimal-length of the keybuffer within btrieve-calls?
especially Get Next (6):

actually we always pass a buffer of 140 bytes (the actual keylength is
8 byte, the rest of the buffer is unused).

Is 140 enough?





Am 04.03.2010 14:45, schrieb nmm:

The key buffer needs to be large enough to hold the key value that you
are retrieving. If your key length is 8 bytes, then the key buffer
needs to be only 8 bytes.

Also, please note that the key buffer, the key number, and the position
block should NEVER be altered between calls. If you alter the key
buffer, overwrite it, or even provide a new key buffer pointer on a
GetNext call, then unexpected results may occur.

If you've already reported to Pervasive, then you should have also
provided a simple, and duplicatable test case. Once they duplicate the
problem, they can help determine what is wrong in the engine (or in the
code).
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive Training - June 2010 in Chicago ***


nmm wrote:

Thanks for the hints. Unfortunately "simple, and duplicatable test
casees" are quite difficult to produce: the problem seemingly only
occur in environments with many (20+) active users.

Pervasive has allready send me a note, that they are not longer
responsible for PSQL 8 and 9, which is a very, very usefull hint, in dead.

After further testing, actually we now have the impression, that the
problem in V10.x will not occur: our further observation of the
phaenomenon in 10.x - we now know - has other reasons (in this cases
the key itself has been changed by other clients during the run).

We checked our code again, and are quite shure, that we always use
just the same keybuffer (140 Bytes long). Elongation to 255 bytes does
not bring much: the problem persists.

We oberved on the computers in question, there can be fount a DLL
w3cache.dll from Microsoft (something like "Tsunami Chache", dont know
what this is): but there is a DLL-nameconflict with a PSQL DLL also
named w3cahce.dll.
Can this be the reason? I have checked: w3cache.dll is not longer a
part of PSQL in PSQL 10.x: there is no suich DLL in a 10.x installation.
There where no error messages at all about dll-problems, but may be
just this DLL causes the doubbeling-problem? (speculativ, ok, but
Pervasive is obvieoulsy not willing to give information about that).

Regards
Mircea

Am 08.03.2010 16:08, schrieb BtrieveBill:

Could indeed be a DLL conflict -- interesting observation. You should
have the Client Cache Engine disabled in any event -- this engine
sometimes causes weird problems. It should be disabled both at the
server (Allow Cache Engine Connections=No) and at the client (Use Cache
Engine=No).
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive Training - June 2010 in Chicago ***


nmm wrote: