|Subject||Re: [IBO] column list & variable list do not match (SOLVED)|
>Yes it did.
> Did setting RecordCountAccurate to false fix the problem?
(warning: about to waffle on to try give thorough explanation & ask
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
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.
>Yes, (observing the trace) my statement was intact, but then there was
> It's not "screwing around" with your statement - the statement object
> itself remains intact.
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 accurateoutput
> recordcount, IBO is using the statement tries to construct another
> (separate) SELECT COUNT(*) query by prepending " count(*), " to the
> fields, probably because you're running the report in ReadCommittedcircumstances!).
> isolation (which is never a good thing for reports under any
>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
> 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. Itdoes what
> it does. As the owner of a full licence to QuickReport, I spent alot of
> time communicating with its authors around Delphi 4 (we're talking1997-98
> here) and they had clearly already given up on it, even then. It was aUnderstood. But as I'm not yet convinced this is purely a QR issue,
> baby that grew out of its pram. Keep things simple and it will do it.
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.
PS I have recreated this problem with a completely fresh form/report