Greetings,
I have a output set consisting of a Constituency End Date that is looking for a NULL value. I have set up the fields where the data select is !.end_dt looking at the view VXS_CONST_CUST. The where area is defined as:
constituency = <<p4>> and end_dt is null
The output set has this and nothing else. A search HH is checked. I receive an error message that states:
The columns constituency and end_dt are ambiguous. I was peering into RP_RUNQUERY and noticed that there is only one table alias allowed for the work table, hence the error. Has anyone worked out the solution to something like this?
Hi Troy
You mentioned you have the Search HH checked and I suspect your element is checked as a single row (constituency = was my clue). In that case, in the Where Clause part for TR_QUERY_ELEMENT make the statement
!.constituency = <<p4>> and !.end_dt is null
If you don’t have !. for where clause fields you get the ambiguity error when you have a combo of Search Household and Single row. The idea is that it acts like the Membership elements – if the constituent on your list has the data then that data is output (even if the household also has the data). If the constituent doesn’t have the data, but the household does then the household data is output. So you only ever get one row output.
!. is used by the aliasing process you noticed in RP_RUN_QUERY
Hope that resolves it for you!
Sandra
From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Troy Nelson Sent: Wednesday, 26 June 2013 6:17 AM To: Sandra Ashby Subject: [Tessitura Technical Forum] Ambiguous column name in Output Set Report
This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!
I will try that.
Yes! That did it. The funny thing is that 90% of the TR_QUERY_ELEMENT parameters do not use the alias in the where clause. It looks like some house cleaning is in order. Thanks for the solution Sandra.