>
> Did setting RecordCountAccurate to false fix the problem?
>

Yes it did.
(warning: about to waffle on to try give thorough explanation & ask
relevant question)

I never use count(*) anywhere due to the known overhead with it,
but the way I inadvertantly called for it, and finding the solution
with your & Jason's help has led me to being a touch confused (how
unusual!) and wanting to understand whats going on. I need to know if
I should write this off as a QuickReport quirk, or realise that it's
from my lack of understanding.

I was originally getting the error twice prior to the report opening.
I realised a (discretely placed) QRSysData component with Data :=
DetailCount could possibly be the issue. Half right. Once that was
gone, I was now getting the error _once_ prior to the report executing
correctly.

Then, from Jasons suggestion, I traced the sql being passed & found
the unexpected line in the opening report's statement:
SELECT COUNT(*) FROM PTI <--COUNT unexpected
...
SELECT ID, REFNUM, BOXNUM FROM BDOWN

This led to me remember also the RecordCountAccurate property in TIBQ,
and once I set it to False the error was gone.

After more fiddling around I found that there's a distinct,
reproducible pattern here. In when the COUNT(*) is unwantingly placed
in my query.
(the table below is neat in monospace)

IB.RecCnt | QRSys.Count | Error
--------------------------------
x | x | Twice
x | . | Once
. | x | None
. | . | None


The only time the error occurs (once or twice) is when the
TIBOQueryroperty RecordCountAccurate is true. It does not happen when
only the QRSysData.Data = DetailCount, or when neither exist.

>
> It's not "screwing around" with your statement - the statement object
> itself remains intact.

Yes, (observing the trace) my statement was intact, but then there was
another second statement which included the COUNT(*).
When _only_ QRSysData was set to DetailCount (ie TIBQ.RecCountAccurate
= False), there was no error and the trace showed only my statement.

So to me it seems like an inadvertant error produced by the TIBQ property.

I don't use TIBQuery components anywhere except on reports, and then
only by necessity, but due to this necessity I really want to know
what's going on here.

> What's happening is that, when the application asks for an accurate
> recordcount, IBO is using the statement tries to construct another
> (separate) SELECT COUNT(*) query by prepending " count(*), " to the

output

> fields, probably because you're running the report in ReadCommitted
> isolation (which is never a good thing for reports under any

circumstances!).

>

Nope, all my reports use tiConcurrency.
I understand the prepending COUNT(*) due to the RecCntAccurate. Makes
perfect sense, but why is it there twice if both RecCntAccurate &
QRSysD.DetailCount are set, but not there at all if only
QRSysD.DetailCount is set?

>
> But I don't know of any way to get a count like this from a regular

UNION

> statement.

But I don't even want the count. I don't have it in my DSQL & I'm
happy to remove the QRSysData component.

> QuickReport is very old and was written for Paradox, anyway. It

does what

> it does. As the owner of a full licence to QuickReport, I spent a

lot of

> time communicating with its authors around Delphi 4 (we're talking

1997-98

> here) and they had clearly already given up on it, even then. It was a
> baby that grew out of its pram. Keep things simple and it will do it.

Understood. But as I'm not yet convinced this is purely a QR issue,
I'm very curious to know.

If you've gotten this far I commend your efforts. I know it's a long
post but I wanted to try to be clear.


After all that, if there's a suggestion I'd love to hear it.

Rgds,
-Ryan

PS I have recreated this problem with a completely fresh form/report