> >Now in BDE-world, inserting a row in dtDetail would automatically
> >assign the value of dtMaster.INTROWID to the field

dtDetail.MASTER.

> >But with TIBOTable, the value of dtMaster.INTROWID is assigned
> >to the field dtDetail.INTROWID instead - dtDetail.MASTER is left
> >unassigned .
>
> This is only true for ISAM databases (Paradox, Access, etc.) so I'm
> guessing that you didn't test it with IB.

Well, indeed, I didn't test it with IB. I used firebird instead.
I hope this doesn't change firebird in an ISAM database ? :-)

> It doesn't apply to InterBase,
> for which parameterised queries are used (yes, even on TTables) to
> implement master-detail relationships.
>
> The "default" way for the BDE to determine a detail-to-master

relationship

> where the detail is a query (which is always the case with a

client/server

> database) is to match fieldnames. That is, it will form the

relationship

> on any pair of field names that match by both name and data type.

Well, the default way I was setting up a master-detail-relationship
in the past was to click on masterfields; in the field connection
designer popping up now, the fields of the detail-table are listed
on the left, the fields of the master-table are listed on the right.
I simply chose the preferred ones (Master on the left, IntRowId
on the right) and that's it.
This procedure worked fine for me
- using the BDE to access Interbase for about five years now without
any flaws
- with a database consisting of 217 tables; 118 of them are detail
(or even detail-detail-detail...) tables.

>
> You cannot rely on IndexFieldNames to enforce the relationship,

since

> Interbase forms its own index with a name such as RDB$FOREIGN99 on

the

> column or columns that form the referring structure. Even if you

have a

> user-defined index on MASTER, InterBase can't be relied on to

associate it

> with the foreign key relationship. (You should *NOT* place an

index on a

> foreign key that duplicates this automatically created index,

btw...)
This explanation I do not understand.

The relationship itself is defined and enforced because of a
referential constraint in the database server itself.
Talking of a RDBMS, I guess that any use of "IndexFieldNames" will
somehow be translated to some kind of "order by" which should work
as long as the field exists; regardless of any existing indexes and
regardless of their names.

I do not demand from Interbase to associate some field or index with
some foreign key relationship.
I do demand this ability from the middleware (IBObjects).
IBObjects does not offer any field connection designer as the one of
the BDE described above.
So to achieve a master-detail-connection with TIBOTable, I just
observed the results of using the BDE-field-designer (setting
IndexFieldNames and MasterFields) and did the same with TIBOTable.

If I understand you right, you argue that for some reason IBObjects
is unable to know about this master-detail-relationship ("you cannot
rely on IndexFieldNames ...can't be relied on to associate..."):
But this is not true:
When *scrolling* the master-dataset, the matching detail-records are
absolutely correctly shown (in a grid);
so IBObjects *basically* knows very well how to associate
the "master"-field of the detail table with the "introwid"-field of
the master table.
My problem appears only when *inserting* a row into the detail table:
The value of the primary key of the master dataset is not assigned
to the "master"-field of the detail table but instead to
its "introwid"-field

> Although you say that your example is "trivial", you have in fact

made it

> non-trivial by confusing the master-detail relationship by having

both

> INTROWID and MASTER in the detail table, with Detail.INTROWID not

being the

> foreign key column.

Well, at least it is trivial enough for the BDE to not get confused !
Now reading the claim
"IBO emulates the BDE 100%
Every feature and capability of the BDE based components that
pertain to InterBase are emulated in the TDataset based components
of IBO"
and being well aware of the "What IBO Doesn't Support"-section
("TTable :
BatchMove, CloseIndexFile, LockTable, OpenIndexFile, RenameTable and
UnlockTable methods.
DefaultIndex, Exclusive, IndexFiles, IndexNames, TableLevel and
TableType are not supported.")
and having in mind that IBO knows of that master-detail-relationship
when simply scrolling that master-detail-combination,

I now dare to talk of a bug in IBO.

>
> To fix, nil out the IndexFieldNames property and either:
>
> Change the Masterfields property of the Detail Table to
> MASTER (alternatively trying the syntax
> DetailTable.MASTER=MasterTable.INTROWID, substituting in the real

database

> table names, of course)
>

Having done both alternatives (well, to be true, it should
read "Change ... Detail Table to INTROWID" instead of
"Change ... Detail Table to MASTER"), but it did not help !

> or
>
> Take charge of the detail query yourself by placing it into a

TIBOQuery and

> providing a parameterised SQL statement, e.g.
>
> MyQuery.SQL.Add ('select <fieldlist> from DetailTable');
> MyQuery.SQL.Add('WHERE MASTER = :master')
>
> In the second case..
> -- a <fieldlist> is preferred, although you can use SELECT *
> -- there is no MasterSource property - use the Datasource property

instead

> -- set the query's ParamCheck property to True in order to have

the master

> table's primary key feed through to the detail query's :master

parameter.
Well, recreating hundreds of master-detail-relationships from ground
up, isn't exactly what I understand when reading
"[...]existing applications will need only a global search and
replace of unit and class names [...] very little fuss should be
required"

> I'd recommend going the second way, since you are soon going to

discover

> how detrimental a Table component is in client/server work.

Over the last few years I discovered that the ttable-solution
is "good enough" for about 80% of my application,
-- about 20% of the remaining "is a little bit slow" and then there
are some few (but important) *hot* spots. It is mainly the hot
spots (and the 20% in the medium term) why I decided to switch to IBO
and I will rewrite them with native IBO components.
But I don't see any need why I should fiddle around with some not
very interesting legacy code which at least worked correctly
(concerning master-detail-relationships) with BDE.

Anyway, thank you for your support.
Kind regards
Frank Emser