| Subject | Re: [IBO] Re: TIBOQuery Master-Detail isn't working anymore |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-02-04T22:18:13Z |
At 08:50 AM 5/02/2009, you wrote:
If you don't refer to the TFields in code, *don't recreate them*. Delphi will create its own TFields internally at run-time if needed. 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.
If you do refer to the TFields in code, consider fixing up the code so that it refers to the columns and parameters only through the 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
>Hi, Dimitry!Check whether you created persistent TFields for these sets in their old form. If so, you need to delete them. If you are referring to 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.
>
>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.
If you don't refer to the TFields in code, *don't recreate them*. Delphi will create its own TFields internally at run-time if needed. 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.
If you do refer to the TFields in code, consider fixing up the code so that it refers to the columns and parameters only through the 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