|Subject||Re: [IBO] Trouble with inserting row in TIBOTable when used as a detail dataset|
> >Now in BDE-world, inserting a row in dtDetail would automaticallydtDetail.MASTER.
> >assign the value of dtMaster.INTROWID to the field
> >But with TIBOTable, the value of dtMaster.INTROWID is assignedWell, indeed, I didn't test it with IB. I used firebird instead.
> >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.
I hope this doesn't change firebird in an ISAM database ? :-)
> It doesn't apply to InterBase,relationship
> 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
> where the detail is a query (which is always the case with aclient/server
> database) is to match fieldnames. That is, it will form therelationship
> 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
- 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,
> Interbase forms its own index with a name such as RDB$FOREIGN99 onthe
> column or columns that form the referring structure. Even if youhave a
> user-defined index on MASTER, InterBase can't be relied on toassociate it
> with the foreign key relationship. (You should *NOT* place anindex 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
> Although you say that your example is "trivial", you have in factmade it
> non-trivial by confusing the master-detail relationship by havingboth
> INTROWID and MASTER in the detail table, with Detail.INTROWID notbeing 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
and being well aware of the "What IBO Doesn't Support"-section
BatchMove, CloseIndexFile, LockTable, OpenIndexFile, RenameTable and
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
> 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 !
> orTIBOQuery and
> Take charge of the detail query yourself by placing it into a
> providing a parameterised SQL statement, e.g.instead
> 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
> -- set the query's ParamCheck property to True in order to havethe master
> table's primary key feed through to the detail query's :masterparameter.
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
> I'd recommend going the second way, since you are soon going todiscover
> 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.