At 08:20 AM 19/04/2005 -0700, you wrote:

>Thanks for the info Helen.
>
>There are on-hand numbers in the query - no problem there.
>
>
>
>I've been bitten by the ambiguous field names in queries even in FB 1.03 and
>I think I've got them all cleaned up. I don't see any problem in the query
>in question other than maybe omitting the S. for 4 columns at the end.

What about the omitted qualifiers in the first four ?

>I also don't have user names in the database itself. Something I've looked
>at briefly, but it seems user maintenance is a pain from an application and
>I prefer my users no getting into IBO Console or some similar tool to add
>users. Maybe IBO 4.5 has something to help out here? I would love to have
>the user ids/permissions a part of the database.
>
>
>
>I guess it comes down to, is the following query valid (now and in the
>future):
>
>(is having a parameter part of the select columns ok?)

I *still* don't believe so. It would be interesting to see whether you get
it to work as you expect without problems. As I mentioned before, changing
the *composition* of the SELECT list in any query invalidates the
statement, i.e.

SELECT 'CARROTS', VEGE_ID FROM VEGETABLES

is a different statement from

SELECT 'POTATOES', VEGE_ID FROM VEGETABLES

and both are different from

SELECT 99, VEGE_ID FROM VEGETABLES

The query prepared for 'CARROTS' would fail for 'POTATOES' or 99, since the
pseudo-field has been inferred by the engine to be varchar(7) for
'CARROTS'...and so on.

>SELECT :USERID, T.COMPANY, T.DIVISION, T.ORDERNO, <etc.>
>
>FROM MY TABLE T
>
>WHERE
>
> T.COMPANY = :COMPANY AND T.DIVISION = :DIVISION

You seem to have missed the point about the ambiguous subquery. The
qualifier/aliasing restrictions apply when joins are in the query or in
subqueries.

Whatever...

Helen

Helen