At 07:50 AM 28/10/2004 +0000, you wrote:

>--- In firebird-support@yahoogroups.com, I wrote:
>
> >
> > The server doesn't crash...but these two queries fail with ISC ERROR
> > CODE:335544652, "multiple rows in singleton select", which I think
>helps to > pinpoint where the AV is occurring.

Update on this - the above result (the two non-crashing queries) was due to
user error. :-)) Sorry Mihai. But don't misunderstand me. I wasn't
telling you that the first query was OK. Go back there, you'll see I
confirmed your observation as totally reproducible.

>Could you tell me on what version of firebird did you run the script?

1.5.1.4481

>I ask you this because I use the 1.5.1 and I don't get the results you
>say. And the fbserver does crash when executing the first select:
>SELECT
> TB1.CREATE_DATE,
> 'xxx' xxx,
> SUM(TB2.QUANTITY)
>FROM
> TB1
> INNER JOIN TB2
> ON TB2.TB1_ID = TB1.TB1_ID
>group by
> 1,
> 2
>
>I get an error window:
>---------------------------
>fbserver.exe - Application Error
>---------------------------
>The instruction at "0x0048ae4e" referenced memory at "0x00000001". The
>memory could not be "read".
>
>
>Click on OK to terminate the program
>Click on CANCEL to debug the program
>---------------------------
>OK Cancel
>---------------------------

For me, the server crashes (every time) but I don't get the AV message
(Win2K Pro). Guardian just restarts the server without any problems.

But I didn't run the selects from a script....

>and after I click OK I get in isql (the script is executed in isql):
> CREATE_DATE XXX SUM
>========================= ====== =====================
>
>1858-11-17 00:00:00.0000 0.000
>Statement failed, SQLCODE = -901
>
>connection lost to database

Yes, to reconfirm, I got this output when running the "crash" query in isql
as well, the same strange result (zeros in everything, no actual data).

>and the firebird.log:
>xxx (Client) Wed Oct 27 15:36:31 2004
> INET/inet_error: connect errno = 10061

Confirmed, the same.

>If instead of the first select query I run:
> SELECT
> TB1.CREATE_DATE,
> 'xxx' xxx,
> SUM(TB2.TB2_ID)
>FROM
> TB1
> INNER JOIN TB2
> ON TB2.TB1_ID = TB1.TB1_ID
>group by
> 1,
> 2
>
>I get (in isql):
> CREATE_DATE XXX SUM
>========================= ====== =====================
>
>2004-10-26 00:00:00.0000 xxx 3
>2004-10-27 00:00:00.0000 xxx 7
>
>which is the correct result and if I run:
>SELECT
> TB1.CREATE_DATE,
> CAST('xxx' AS CHAR(3)) xxx,
> SUM(TB2.QUANTITY)
>FROM
> TB1
> INNER JOIN TB2
> ON TB2.TB1_ID = TB1.TB1_ID
>group by
> 1,
> 2
>
>I get:
>
> CREATE_DATE XXX SUM
>========================= ====== =====================
>
>2004-10-26 00:00:00.0000 xxx 8.000
>2004-10-27 00:00:00.0000 xxx 8.000
>
>which is the correct result too.
>
>I included these last two selects to show that the same select query
>that crashes the server with little modification (the sum made on an
>integer field instead on an numeric one, or a cast to char(3) over
>'xxx') works.

All confirmed, as before, except ignore the "multiple rows in singleton
select" note as a "stoopid-user" error.

Could you put that bug-report up into the tracker today?

./heLen