| Subject | Re: TIBOQuery Master-Detail isn't working anymore |
|---|---|
| Author | Antonio Carlos Ribeiro |
| Post date | 2009-02-04T23:52:40Z |
--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
them in code, then you will need to re-add them. I think what is
happening at the moment is that Delphi is trying to make sense of the
"old" TFields. IBO 4.8 has had field binding radically tightened up to
meet the stricter rules in Firebird 2.1. Now, with your detail field
references properly renamed, those old TFields are no longer valid.
I think that is what it is already doing, because of invalid TFields:
you observe that the filter only works if you refresh the detail set
each time the master record changes.
properties and methods of Fields and Params arrays. Those old
design-time persistent fields are a Paradox feature that was never
efficient for client/server databases. By avoiding them, you save
some considerable overhead in a lot of places. You also reduce the
risk of encountering problems with binding detail records to masters
at run-time.
Based on your explanation I made another master-detail relation work
correctly and after that, with a path, I discovered the problem: I'm
not allowed to change the SQL on a BeforeOpen event. My application
has some procedures that (re)writes application main sql queries, so,
yes I'm dumb, I've made a routine to fix those, now forbidden,
'aliasesless' SQL queries, and where's the best place to assure that a
SQL is righly written? Just before open it, of course! I didn't
thought IBO would not accept it.
Thank you (ALL!) really much for your help.
Antonio
>old form. If so, you need to delete them. If you are referring to
> At 08:50 AM 5/02/2009, you wrote:
>
> >Hi, Dimitry!
> >
> >Now aliases are different in master and detail, but it doesn't matter,
> >after opening both tables, skipping to the second record record in
> >master, detail seems to loose connection with master datasource.
>
> Check whether you created persistent TFields for these sets in their
them in code, then you will need to re-add them. I think what is
happening at the moment is that Delphi is trying to make sense of the
"old" TFields. IBO 4.8 has had field binding radically tightened up to
meet the stricter rules in Firebird 2.1. Now, with your detail field
references properly renamed, those old TFields are no longer valid.
>Delphi will create its own TFields internally at run-time if needed.
> If you don't refer to the TFields in code, *don't recreate them*.
I think that is what it is already doing, because of invalid TFields:
you observe that the filter only works if you refresh the detail set
each time the master record changes.
>so that it refers to the columns and parameters only through the
> If you do refer to the TFields in code, consider fixing up the code
properties and methods of Fields and Params arrays. Those old
design-time persistent fields are a Paradox feature that was never
efficient for client/server databases. By avoiding them, you save
some considerable overhead in a lot of places. You also reduce the
risk of encountering problems with binding detail records to masters
at run-time.
>Helen,
> Helen
>
Based on your explanation I made another master-detail relation work
correctly and after that, with a path, I discovered the problem: I'm
not allowed to change the SQL on a BeforeOpen event. My application
has some procedures that (re)writes application main sql queries, so,
yes I'm dumb, I've made a routine to fix those, now forbidden,
'aliasesless' SQL queries, and where's the best place to assure that a
SQL is righly written? Just before open it, of course! I didn't
thought IBO would not accept it.
Thank you (ALL!) really much for your help.
Antonio