--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> That isn't possible. You can't "set" values for a stored
> procedure, since it has no existence as a table object in the
> database.

I know, that's why I have defined an explicit InsertSQL that specifies
only the table. The problem is that when I set the 'num' field it
doesn't really get the value. My guess is that the other 'num' field
gets it.

> >2. I tried to be clever and use the fully qualified name -
> >query['aaa.num']:=... only to discover that IBO ignores the table
> >name and only uses the field name.
>
> IBO can't do DSQL that the engine doesn't support. SQL does not
> support referring to multiple tables in an insert statement

If you take another look at the InsertSQL I've explicitly defined,
you'll see that it is a simple single table insert.

> Since no joined set is naturally updatable, the use of aliases won't
> make any difference to the "updatability" of the set. In SQL
> joining, aliases resolve ambiguity. It's ironic that you object to
> column aliasing as cumbersome, when you have chosen just about the
> most cumbersome approach imaginable to solving the overall problem!

Since I don't need to update or insert a joined set, only a single
table, and since my InsertSQL does just that, I don't really see how
my method is cumbersome at all.

I know it's possible to use a seperate TIB_DSQL for the inserts, but
why? Every TIB_Query contains several TIB_DSQLs for select, insert,
update, delete, etc. I don't really see the point of ignoring those
and using a separate TIB_DSQL that does exactly the same thing as the
one inside TIB_Query.

Maybe you didn't understand what's the problem that I described. I do
NOT expect IBO to generate an insert SQL statement from a joined
query. I explicitly provide the correct insert SQL.

The problem is that there is no way to access the correct field in a
dataset, when the query returns two (or more) columns with the same name.

Eyal.