Hi Helen, thanks for your reply...

I've been looking at the IBO units .pas files and fixing what I can -
notably the bits where an RDB$ system table is aliased in a query and,
at the same time, its full name is used to reference a field in a
query. This seems to have helped an awful lot. I can now use the
queries as I originally wrote them without adding the extraneous fields.

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> IBO doesn't care about indexes. The problem probably is down to its
> being unable to determine the KeyLinks.
> -- How are you setting these?
> -- Are you trying to make RequestLive true on a query of this type?

Well... I'm not! Am I meant to? I've seen that bit of the query set up
screen and kind of stared stupidly at it. Does this in fact need to be
filled in?
I don't know what a RequestLive query is. Is this some construct that
allows direct editing of data? If so, that's not what I'm trying to
do. Think, take a TIBQuery, grab the SQL out of it, and paste it into
the TIBOQuery.


> What do you mean by "where BKMFBNUM is an index"? It's not valid SQL
> to put a count on an index. Did you really mean "where BKMFBNUM is
> an indexed column"? If the latter, having an index on a column makes
> no difference to COUNT(), although it might make a difference on the
> server side for sorting (GROUP BY and ORDER BY). IBO simply doesn't
> know or care whether you have it indexed or not.

You're absolutely right, I wasn't clear - BKMFBNUM is in fact an
indexed column.

> In the past we've seen people using ClientDataSets "for the
> convenience of some of the ... features" when in fact the IBO
> datasets already implement those features. Problems seem to occur
> when the CDS asks to do something that the IBODataset implements
> differently to how CDS expects its providers to behave. So it's a
> bit of a Pandora's box when you're using CDS for purposes other than
> to provide a remote client data layer for a data access layer that's
> operating on the server, i.e. an n-tier app.
>
> It seems to be an issue when people are migrating from IBX to IBO,
> because the IBX dataset implementation needs the extra CDS layer in
> order to implement bi-directional scrolling. I also recall
> situations where the CDS methods fooled around with the keyfields and
> made (otherwise good) IBO KeyLinks appear to be invalid....

The features I'm really referring to are the ability to add aggregates
to a dataset. So, taking the example I used earlier...
SELECT EXTRACT (WEEKDAY FROM SAILDATE) AS SAILDOWORD,
DOW (SAILDATE) AS SAILDOWDESC,
COUNT (SAILDATE) AS SAILINGS,
SUM (PAX) AS PAX
FROM SAILINGDATA
WHERE SAILDATE BETWEEN :D1 AND :D2
AND DEPARTUREPOINT = :P

GROUP BY 1, 2
ORDER BY 1

... I want to add a field called TSAILINGS defined as an aggregate on
my client dataset, and define its expression as SUM(SAILINGS). this is
awfully convenient.... is there a smart way to do this using, say,
IB_Querys?

I'm experimenting at the mo with two IB_Querys attatched to two
IB_Datasources, with the second having the first's datasource as its
Master datasource.
The first query is similar to the one listed above, -

SELECT SAILDATE,
COUNT (SAILDATE) AS SAILINGS,
CAST(:D1 AS DATE) AS D1_OUT,
CAST(:D2 AS DATE) AS D2_OUT
FROM SAILINGDATA
WHERE SAILDATE BETWEEN :D1 AND :D2
GROUP BY 1, 2
ORDER BY 1

The second looks like

SELECT COUNT (SAILDATE) AS SAILINGS,
FROM SAILINGDATA
WHERE SAILDATE BETWEEN :D1_OUT AND :D2_OUT

I have the MasterParamLinks for the second set up as
D1_OUT = D1_OUT
D2_OUT = D2_OUT

Then I close the first query, change its parameters and open it again.
Finally I close and open the second. This seems a bit clumsy and I'm
probably getting this a bit wrong too. There's probly a better way to
get the second query to use the same :D1 and :D2 parameters as the
first one, but I can't see it.

Thanks so much for your help Helen... if you can see anyway of doing
this better I'd appreciate it...

Regards,

---=Laurie