Hi
again we made a strange observation (PSQL 9.x and 10.x).

We have a application written with delphi6 unsing btrieveAPI. If we
open a btrieve-file, we send opcode 0, 15 and 13.
This works fine for us, but only if the file we open is not segmented
from PSQL. If it has segments, than the application crashes from time
to time with varying exceptions (not allways the same type of
exception: invalid pointer op, stack overflow, extection while writung
to adress #nnnnnn and so on), but not immediate after the
btrieve-calls (they return status 0).
The open-procedure runs through exactly the same code.
If the file is not segmented, all is fine, if it is segmented, than
the errors occur. This reproducible, but we can not determin a point
in the code, from where the errors rise, because these are at each
occurence different - and we can not find any system in this.
(we have the source-code of that applicatiuon an can debug it unsing
Delphi).

This strange things happen in PSQL 9.x as well as in PSQL 10.x (server
and workstation engines), but seemingly not in PSQL 8.x!

We switched off segmentantion and run a rebuild on that segmented
file: after this, the error does not occur.

BTW: the files in question are by no means corrupted: we made a test
on different machines with different created files: it is simply as
described: if it is segmented, than the eroors occur, if not, than not.

We still tried to use a bigger buffer for pos_block (255 bytes, not
128 as demanded), because the only thing we can imagine, is that the
btrcall-function wirtes more data the the pos_bloc, than it should:
but this does not solve the problm.



My question is:
-is there anything, that has to be considered on the client, if the
file in question is segmented?
-does anyboday make a similar obseravtion and has any idea, what the
reason is?


I would guess, that segmentation should be completely transparent to
the clinet, but seemingly there is something different.

Any hint will by highly appreciated!


Regards
Mircea

I have never seen anything even approaching this symptom in all of my
travels. My first inkling is that there is some other process which is
interfering with the file access, such as an Antivirus application.
Many people remember to exclude their prmary database extension from the
AV scanning, but they forget to also block the ^01, ^02, and other
related extensions.

My second thought is that if this is ONLY a problem on PSQLv9 and
PSQLv10, both of which fully support large, single-file tables, that
yuou should consider rebuilding the files into a single extent anyway.
This typically improves performance, makes it easier to administer the
system. You should ONLY do this if you are running v9.5 or above --
PSQLv9.1 and older had some problems with this setting.

Third, I cannot imagine that anything would touch the client side of the
equation -- this doesn't seem to make much sense at all...
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive Training - October 2009 in Chicago ***


nmm wrote:

Hi Bill, thank you for your endeavour in this matter!

Encouraged by your remarks, yesterday I accomplish further debugging,
because I said to me, that if you have never seen something like that,
then it *must* be a bug in our code.

Actually I found it! Here it is:

we use the function BTRCALL (not BTRV): and in BTRCALL one can pass
the keylength. The STAT-Cammand (Code 15) returns something in the
keybuffer, if the file is segmented (actually the filename of the
first segment), if not(segmented), it returns only one byte: #0. This
was new in PSQL9. We allways pass a keylength of 4 and as keybuffer a
longint.

In PSQL7/8 the passed keylength was respectet by the API(or in
keybuffer allways was returned #0?), in PSQL 9/10 seemingly not: the
BTRCALL-function returns more bytes in the keybuffer, than specified
in keylength: because we only had a longint-Variable, this collateral
bytes destroyed parts of the object-tables from the Delphi-VCL, so we
get this obscure beahvior.

Now we pass 256 byte keybuffer (as specified in the
btreive-API description V9.5), and all is fine again.

Thanks agin.
Mircea


BtrieveBill schrieb:

Interesting. The documentation for the STAT call does indicate:

What I actually expected to see, if you properly specified a KeyLength
of 4, is a Status 21 get returned. Please check the setting in your
client for "Verify Key Length" and make surew that this is set to ON
(Checked). If disabled, additional memory corruption can arise.

If you find that the key length is being verified, and you indeed have a
4 for the key length on this call, then this sounds like a bug in the
client that needs to be fixed.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive Training - October 2009 in Chicago ***



nmm wrote:

"Verify Key Length" was already set to ON(the whole time). Actually
keybuffer and keylength are not used in connection with keys/indices
in the STAT command, so may be pervasive does not (longer?) check
keylength in STAT?
(the 4 for the keylength is "hard codeed" in our call of STAT, so its
really a 4).

Regards
Mircea

BtrieveBill schrieb:

I never use the BTRCALL function, favoring instead BTRV, which does not
use the extra parameter. I'll need to build a test application to
confirm if this is a bug or not.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive Training - October 2009 in Chicago ***


nmm wrote: