Hi Dmitry,

Dmitry Yemanov wrote:

> "Geoff Worboys" <geoff@...> wrote:
>>
>> But this does raise the question of why the server should abort
>> when filtering BLR fields. Note that the server aborts are
>> inconsistent (do not occur on same procedure BLR every time).

> This looks like a subtle bug in the builtin blob filter for
> BLR. I'd like to have a more-or-less reproducable test case.
> Appearance of this bug should have a direct relationship with
> the BLR code stream, perhaps some of the new v1.5 features is
> a problem.

I've tried lots of things to create a reproducable test case.

First I created a small table containing just the BLR field of
all the procedures in the database (it was always on the
rdb$procedures table that it failed). A total of 211
procedures, some small and some quite large.

Then I tried pumping those BLR blobs into text blobs - figuring
that that should exercise the filters. It went through this
several times... quite slow but otherwise no problems.

Then I introduced one of my UDFs that reads strings from
blobs. Selecting text from the blobs using this UDF did not
show a problem - but may not have been filtering anyway, not
really sure.

Then I wrote a program to read all these BLR fields as strings
from the save BLR fields. This is essentially what is
happening in the DBak program - but again I could not produce
an error even after about 20 iterations.

So whatever the conditions that DBak produces to cause the
engine failures are quite subtle. It is not a simple BLR
translation problem, there must be a timing issue of some sort
in there too.

DBak uses the Metadata extract component of IBObjects, as does
the metadata extract facility of IB_SQL. I was able to blow
up the server 2 times out of 3 by using an unfixed version
IB_SQL (one that still has the metadata extract reading the
BLR) on the original database.

Is there something I can do here to capture more information
when the server aborts?

--
Geoff Worboys
Telesis Computing