>>>It may be something that Jason wants to look at more closely,
>>>however it is always best to name your parameters differently to
>>>the field names.

> Geoff,

> That indeed works. However, I have found examples that suggest that
> you use the same name. (See page 129 of Borland Data Definition
> Guide, Ver 4.0) I think other folks will fall into this trap too. :)

Hi Marv,

I think that under most situations the use of parameters with the same
names as fields in the main SQL statement is not a problem. The
insert/edit/delete sql are different statements and there should not
normally be any conflict. (fields in the main statement are matched
with parameters in the insert/edit/delete sql and so the parameters
of the main sql are not seen.)

Exactly why you should have had a problem in your situation I am not
certain - perhaps it relates to what you had as orderinglinks. For
example *if* you had complainttype in your orderinglinks *perhaps*
that could be the problem (but then it would make no sense to
have it there for your sql, so I dont suppose you did).

The fact that you can resolve the problem by being consistent in using
uppercase does indicate that there is a problem in IBO somewhere.


My advice/suggestion about using a different name for the parameter is
just because I find that my code is clearer and problems are easier to
track down if I use different names for my explicit parameters.
Something like :INPUT_COMPLAINTTYPE means that during debugging, if I
come across a column definition I can see the fieldname and know
exactly what I am looking at.

In SQL such as yours the various names can get quite confusing. Most
of the fields will need relation.fieldname for identification, however
CustomerName (any statement computed field) has no relation and must
be identified only by fieldname. CPID appeared without an associated
statement. IMO the more complex the statement the more critical that
you try to be explicit and consistent to try and minimise confusion.


--
Geoff Worboys
Telesis Computing