At 07:30 PM 07-05-02 +0200, you wrote:

>Hi!
>
>Three questions:
>1. What is your page size? Is it large enough to accommodate one
>record?
>
>Page size is 8K. I think, this large is enought.
>- BIN_DATA max: 600char, BIN_WORK max 300char length -> 1 char=3byte? or
>not? -> 900*3byte=2700 byte
>- 38 integer field = 4byte*38 -> 152 byte
>- 9 datetime field = 8byte?*9 -> 72 byte
>so, max 3000byte real data is 1 record + one index

The page_size has to be large enough to accommodate one row of your table
structure. Your two varchar(4000) columns on their own would require a
page_size of 8K. Add the other columns and we come out at 8224 bytes -
plus a few for page info data. So 8192 bytes is too small.

(and no, you do not have to count 3 bytes per character with WIN1250 - it
is a one-byte character set)

>2. Are you using the proper version of the gds client on all of the
>client machines?
>
>This is a local only system. It use DBExpress. The lastest.

I am not talking about Delphi - I am talking about the Firebird client
gds32.dll, which DBExpress will load upon the first connection. Check the
version number of this library - it should be WI-V1.0.0.794. (Find it in
the system directory).

>
>3. Is it coincidence that the column names of your two large varchar
>columns is BIN_* ? Are you trying to poke binary data into character
>containers?
>
>This fields contain binary datas, that are first compress with zip, and
>encode with a specific code64 algoritm with this chars:
>const CodeList:
>string[64]='+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv
>wxyz';
>I now check, that the BIN_* fields contain only this chars.

Why are you using varchar(4000) for these columns, instead of BLOB?

> 4. Connect string?
>
>On the DBExpress, i cannot see the connect string. Only properties:
>
>Database=127.0.0.1:c:\aaa\wa.gdb <------ this is the connect string.

You mentioned elsewhere that you had 8 threads running on this
connection. This connection is local. Were you aware that the local
connection is not thread-safe?

It seems that you have multiple sources of jeopardy here for memory allocation.
a. the page_size is smaller than the record structure
b. you have 8 threads all stepping in the same inter-process communication
space as the server process.

Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________