> 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)

Then, the varchar(4000) allocate 4000bytes from block, when the data is
only 400 char???

> 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).

I install FB from install. I think, the gds32.dll is correct...
But, i check it, and the version is correct.

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

Because, this system work on ORACLE and MSSQL too, and on ORACLE, i
cannot use BLOB, because, is very slow.
I think, 1000 char text is not a very dangerous size to varchar.

> 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's sure, that is thread safe. This system works since 2 years, and the
problem started since a install new FB, and add the two varchar field.

> 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.

a. OK, page is small. The real data on the varchars is only 600-700
chars, then i change to varchar(2000). Then, the total recsize is only
~5000byte. It is correct?

b. It must be the 8 thread with 8 connection. Then, how a need to
connect to FB? I use 127.0.0.1:c:\ddd\aa.gdb format, then is not TCP/IP
connection instead of IPC?