> Alan,
>
> > I know they're not required, but in all my reports which use
> > IBO (TDataset)
> > components, unless I persist a field which another datasource
> > expects to
> > source FROM, then the sourcing fails. The query itself is
> > fine, but the
> > sourcing fails.
>
> I would consider this a bug and will fix it if you send me a
> sample app that
> demonstrates this problem. I would work on it but I hunch I could easily
> find myself chasing my own tail.
>
> Thanks,
> Jason Wharton

I've got to be honest with you Jason,
1. I have always considered this occurence to be an artifact of the
implementation, not a bug.
2. I have just now picked open one of umpteen examples in my application
code, deleted a persistent field being referenced by a parameter of a detail
query, complied and run the report, and voila, the child query does NOT
return a record. I then replaced the persistent field into the master query,
re-ran the report and voila, the child query returns the designed result
set, i.e. the presence or lack thereof a persistent field in the same name
as the parameter of a datasourcing query prevents the parameter being filled
in that child query. A sample app to demonstrate this seems total over kill
to me.
3. I'd much rather get a solution for why an erratic access violation comes
up randomly whenever I use custom glyphs on my IB_Grids. It's something to
do with the destruction sequence but I can't track it down.

I wouldn't dream of using anything other than IBO for Firebird applications.
Alan