Subject Re: Firebird upgrade 1.0.3 -> 1.5 and crashing of long-running query.
Author tibotaka
--- In, Helen Borrie <helebor@t...>
> OK, I think you will find this error occurs because the client has
> sent a
> Fetch request for the next row from the SP's output buffer but the
> connection to the database has been lost.
I think this is the problem – but why connection to "OLD" Firebird is
lost even the query is running longer?

> Right, a few things here:
> 1. In both cases, this is a heck of a lot of rows to be returning
> to the
> client in a single select....though the size of the dataset
> probably is for
> another subject, probably, since your call is crashing *something*
> after
> only 144 rows have been returned. Do I understand this correctly?
The situation is a bit different. Count of returning rows from this
query is constant (180 result rows). The values in 144 result rows of
crashed query are correct. The "heck a lot of rows" is roughly count
of data rows proceeded by this query during evaluating and not count
of returning rows...

> 3. In the meantime, don't change firebird.conf, but try invoking
> your SP
> using isql, to discover whether anything crashes using the correct
> client
> interface - see (4) below.
I'm trying it right now... But I have to wait for about 40 minutes to
get results...
THE SAME CRASH IN ISQL TOO (Statement failed, SQLCODE = -901,
request synchronization error)...
The last row of result is returned twice with the same values.

> 2. If you are using IB_SQL built with a version of IBO that is
> older than
> 4. IB_SQL expects a client named gds32.dll, located in the
> system32
I'm aware of all this stuff and I'm using the correct Firebird client

The situation is independent of used client application - currently
I'm using both IB_SQL (I have not any client DLL in system32
directory, but I copy relevant client DLL to IB_SQL directory) and
EMS Interbase/Firebird SQL Manager (in this case there is an option
in definition of connection to choose the relevant client DLL).
It is also independent on whether the SQL SELECT is invoked from
client application on remote PC or on the same PC where Firebird
server is running (in both cases I'm using TCP/IP network protocol to