Subject | RE: [IBO] Ambiguous field name? |
---|---|
Author | Helen Borrie |
Post date | 2002-11-05T03:17:21Z |
At 08:54 PM 04-11-02 -0500, you wrote:
LOCATIONID into the equation. I did ask you to show the SQL that the
monitor was indicating, since it is almost certainly different to what you
think you are passing in the SQL property.
I can only guess, but I suspect you have a primary key in there that
involves LOCATIONID. There WILL be KeyLinks used by this query object (and
must be) unless you (erroneously) disabled KeyLinksAutoDefine AND failed to
enter your own KeyLinks.
I suggest you inspect the KeyLinksAutoDefine and KeyLinks
properties. Because it is a joined set, you should set KeyLinksAutoDefine
to False and enter your own KeyLinks, which will need to be a list of
columns coming from each table in the join (Table.ColumnName) that,
together, uniquely identify one row of the output set. If one or more of
those tables has LOCATIONID in its primary key, then you need to include
that column (unambiguously) in the KeyLinks for its role in the joining of
the tables; or, if required, modify your SQL (e.g. with a WHERE
X.LOCATIONID=X.LOCATIONID) to resolve the ambiguity. (That's not offering
a solution, only a pointer to where you could possibly go...)
regards,
Helen
>Both tables involved have a field called LocationID but it isn't used in theThis, then, is probably the source of the parsing error that is throwing
>query. The query I posted is the entire query. There are no GeneratorLinks
>or KeyLinks used by this query object.
LOCATIONID into the equation. I did ask you to show the SQL that the
monitor was indicating, since it is almost certainly different to what you
think you are passing in the SQL property.
I can only guess, but I suspect you have a primary key in there that
involves LOCATIONID. There WILL be KeyLinks used by this query object (and
must be) unless you (erroneously) disabled KeyLinksAutoDefine AND failed to
enter your own KeyLinks.
I suggest you inspect the KeyLinksAutoDefine and KeyLinks
properties. Because it is a joined set, you should set KeyLinksAutoDefine
to False and enter your own KeyLinks, which will need to be a list of
columns coming from each table in the join (Table.ColumnName) that,
together, uniquely identify one row of the output set. If one or more of
those tables has LOCATIONID in its primary key, then you need to include
that column (unambiguously) in the KeyLinks for its role in the joining of
the tables; or, if required, modify your SQL (e.g. with a WHERE
X.LOCATIONID=X.LOCATIONID) to resolve the ambiguity. (That's not offering
a solution, only a pointer to where you could possibly go...)
regards,
Helen