Hello all (addressing myself presumedly especially to Jason),

during the last days I experimented with the
DeleteSQL-Property of TIB_Datasets. I wanted to link tablenames
to params of a Stored Procedures with help of the
IB_SQL-Utility/IB_Query-ComponentEditor (click on the "Create for
procedures"-Button opens the dialog).

Given a Stored Procedure "aSPName" and a Field-Identifier "TableX.FieldY"
that should be linked to a parameter of the stored procedure
setting up DeleteSQL by these means resulted in strings of the format

EXECUTE PROCEDURE aStoredProcName ( :TOLD_ableX.FieldY);

(The OLD_-prefix is inserted behind the first char of the tablename due to
the
test for SQLDialect3; there are two functions - MkOld and StOld - which are
responsible for that; there is just a further test for quotes needed to get
the better looking result of :OLD_TableX.FieldY; Jason, I will send you
this
correction - but in fact this is not essential and this was not yet my
problem).

This strange looking string raised the question, if the OLD_-prefix should
not be inserted in the fieldname-portion of the argument
("TableX.OLD_FieldY").
I discussed this already a little bit with Helen (thanks for your patience
and efforts, Helen).

Not being able to find a quick solution, I did some tests.

Finally I had to realize that the format of the argument didn't matter
at all concerning the tablename portion. The parser accepted almost all
formats I was playing with and the procedures were executed without
complaints.

So valid formats are for example:
TOLD_ableX.FieldY
["]OLD_TableX["].["]FieldY["] (with and without quotes)
and even a identifier
XYZ.FieldY where the tablename XYZ does not exist.

My hypothesis at this point was that the table-identifier is neglected if
not needed.

In the field portion the parser accepted all formats where
it was able to identify the field, so

OLD_FieldY,
OLD_"FieldY",
"OLD_FieldY" or
FieldY (all Forms with ore without Tablename-identifier) are all valid
(here raises the question why the OLD_-prefix
is necessary at all???)

while FOLD_ieldY (the "Field-equivalent" of my starting point) resulted
in an error.

As long as the fieldnames were clear-cut to attach to the arguments,
DeleteSQL
worked well (as seen in the SQL-Monitor).

To this point I did the tests with values from one single relation, so they
differed
in their fieldname portion.

Now I asked myself, what would happen if fields don't differ in their
fieldname and stem from different relations. I designed a stored procedure,
that accepted two VARCHAR-arguments and I linked them to two VARCHAR-Fields
with the same fieldname from different relations.

Formally the DeleteSQL looked like
EXECUTE PROCEDURE aSPName (:OLD_TableX.FieldY, :OLD_TableY.FieldY)
with OLD_TableX.FieldY = ValueA and
OLD_TableY.FieldY = ValueB

The SQLMonitor showed that the first value(respectively only one of both
values) was assigned to both arguments, so it seems that the
tablename-identifier is rejected
also in this case where it is essential for differentiation.

The problem here is that with a joined query that includes two (or more)
fields with identical fieldname but different tablenames it can not be
guaranteed that the correct field is linked to the parameter of a stored
procedure in the UpdateSQL-strings.

Conclusion: If full-qualifiers (Tablename.Fieldname) are needed to link
arguments of stored procedures to queries in DeleteSQL (and I suppose as
well in EditSQL- and
InsertSQL) the tablename seems not to be processed even in cases where it
would be crucial.

Herbert