I was a big fan of datamodule, and when I started my last big project with IBO I followed that approach.
But it's the wrong one with IBO for the following reasons:
- IBO is strictly chained with the visual controls, so if you have same table but two forms using it, and one of the two needs special setting of fields, you need a IB_Query for that form.
- IBO surfaces a lot of properties but, above all, events that lets you fine tune your visual behaviour. So if the query is on the datamodule, you have to chain datamodule code to forms components, messing up your datamodule with code related to n forms, and without any benefit
- Transaction: it's a good idea having a transaction component per form, so you are pretty sure that is often committed (almost when you close the form)

I've one datamodule that contains the connection component, TIB_SessionProps, a transaction component that acts as default transaction for the connection, and code that checks about connection success and, if it fails, asking about connection parameters for a retry.
I've then a datamodule that contains "generic lookups queries". IBO has an interesting approach for lookups derived from it's chain between datasets and visual controls, but this has the only drawbacks that you have to realize a lot of lookup queries that do the same thing but are only used by different control in different forms (i.e. zip code lookup query is always the same, any form uses it).
So I've the code that I run at data entry form startup:
(FormCreate or FormShow, depending if it's dynamically created or not):
ChangeGenericLookupSource( qryGLk_MyGenericLookupDataset,
MyForm_DataSource,
'LOOKUP_KEY.FIELD_ID=FORM_DATASET.KEY_ID' );

and the code:
procedure TdmDataModule.ChangeGenericLookupSource(
LookupDataset : TIB_DataSet; AKeySource : TIB_DataSource; AKeyLink : string; AKeyDescLink : string = '' ; AddSettings : boolean = False );
begin
with LookupDataset do
begin
Close;
KeySource := AKeySource;
if not AddSettings then
begin
KeyLinks.Clear;
KeyDescLinks.Clear;
end;
if AKeyLink <> '' then KeyLinks.Add(AKeyLink);
if AKeyDescLink <> '' then KeyDescLinks.Add(AKeyDescLink);
Prepare;
Open;
end;
end;


For your problem of the relation master/detail with a lot of details chained to one of few masters, it's not very much clear to me.
Anyway consider that, if your "detail" are not "actual" detail, in the sense that you don't use them in conjunction with the master but are master datasets that "dictate" the selection of data you are working on (i.e. the "fiscal year" table dictates all accounting table actual data used by your app), you can "refine" the data to be used in the
OnPrepareSQL event of all your "detail" tables
SQLWhereItems.Add( 'FISCAL_YEAR=' + MasterDataset.FieldByName('FISCAL_YEAR').AsString);

Or better, you can get MasterDataset values in the OnDataChangeEvent, and assign to a global variable to be used in all your forms:
(SQLWhereItems.Add( 'FISCAL_YEAR=' + Gbl_Vars.FISCAL_YEAR);

Hope this will help you :)
Marco Menardi

--- In IBObjects@y..., "Tom Deprez" <zifnabbe@u...> wrote:
> Hi,
>
> Do lot's of you use the TDataModule for placing all the datasets and
> datasources?
> Or are most things just placed on the form.
>
> I'm just asking, since I've several detail datasets who's master changes
> depending on which form the user is wroking on etc, and I kinda think this
> is not a good idea to place everything on the datamodule.
> How do you all this? This is the first time I'm working on such a big
> database application in Delphi.
>
> Thanks, Tom.