Subject | Re: [IBO] Problem with TIBOQuery |
---|---|
Author | Daniel Rail |
Post date | 2005-02-03T12:29:51Z |
Hi,
At February 2, 2005, 16:26, Hans wrote:
TTable. And if you use more than one table for each transaction
component, Commit will be related to more than one TIBOTable, unless
you have one transaction component for each TIBOTable.
in IBO. As Helen already stated, that when using UNION(not UNION ALL)
if there are two rows(one from each select) that are identical, only
one row will be returned. So because of this uniqueness of rows,
summarized counts, as you are using, are useless in this case. But,
if you know that will never happen, in your case, then your changes
will work for you. But, on the other hand, it might not work for
someone else.
And, I would support adding an OnCount event to permit anybody that
would be in a similar predicament as yours, to be able to use their
own record count method.
--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)
At February 2, 2005, 16:26, Hans wrote:
> I agree. There never is 100%, but it is getting close.That's what I was thinking, but FlushBuffers is related to a single
> The closest I can think for FlushBuffers is Commit.
TTable. And if you use more than one table for each transaction
component, Commit will be related to more than one TIBOTable, unless
you have one transaction component for each TIBOTable.
> I would have preferred some OnFlushBuffers eventAlthough it works for you now, I doubt Jason will include your changes
> instead of modifying a lot of source code and directing
> all FlushBuffers to a common MyFlushBuffers(TIBOTable)
> procedure.
> After I modified IB_Parse and IB_Components to
> at least return a summarized UNION RecordCount,
> it surprisingly all starting to work
in IBO. As Helen already stated, that when using UNION(not UNION ALL)
if there are two rows(one from each select) that are identical, only
one row will be returned. So because of this uniqueness of rows,
summarized counts, as you are using, are useless in this case. But,
if you know that will never happen, in your case, then your changes
will work for you. But, on the other hand, it might not work for
someone else.
And, I would support adding an OnCount event to permit anybody that
would be in a similar predicament as yours, to be able to use their
own record count method.
--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)