Subject | Re: [IBO] Cannot prepare a blank statement -error |
---|---|
Author | Andreas Hesse |
Post date | 2009-02-06T09:21:39Z |
So it is time for debugging.
Halt on this exception and see, what object is causing it and what is
the stack trace. Compare the object that raise the exception with the
one that you expect.
Post the information here, so we can help you much better with some more
informations.
Andreas
Halt on this exception and see, what object is causing it and what is
the stack trace. Compare the object that raise the exception with the
one that you expect.
Post the information here, so we can help you much better with some more
informations.
Andreas
> Hi all.
>
>
> I have a case which I can't figure out, and it's really hurting me right
> now. I have an app with about 50 reports, using FastReports. Just a few days
> ago I noticed that two of my reports are throwing "Cannot prepare a blank
> statement" error, which seems to come from IBO. As far as I know, I haven't
> changed anything in those reports in ages, and I checked an older compiled
> version of the app and it worked just fine.
>
> Here's where it gets weird: I set two queries (of TIBOQuery type) at
> runtime. There's a fairly simple SQL in one of them, and a bit more complex
> but nothing strange in the second one, just a few joins. If I do something
> like this after opening the queries:
>
> while not HeaderQuery.Eof do
> begin
> ShowMessage(HeaderQuery.Fields[0].AsString);
> HeaderQuery.Next;
> end;
>
> ....it works ok, I can go through all records without any trouble. But, as
> soon as the report opens, it throws the error mentioned above.
>
> Now, the report may be a culprit here, but I'm dumbfounded as to how to
> start searching for the cause here. The IBO source is way too complex for me
> to wrap my mind around, so I'm posting this here (as well as in the
> FastReport newsgroups) in hopes that someone could at least point me towards
> the solution. Like, in which exact case would that error get thrown usually?
>
> Any help greatly appreciated,
> Antti Kurenniemi
>