Hi all,
For our upcoming Gala, we want to print a single ticket for all patrons that has their name, the section they are seated for a performance, their table number for dinner, and their bidder number. All of this will be entered into Tessitura prior to the event either through a dummy event or attributes. A couple of us have looked over the documentation for updating parts of LP_TICKET_ELEMENTS, but so far our user defined elements are not appearing when a ticket is printed.
The test print version, pulling dummy info from T_Design_Element works, but the actually UDE info from a patron's account doesn't appear when printed. In Test, I have a patron with a ticket to the dummy Gala event, a table number under the event record, and an attribute for their Gala bidder number. In LP_Ticket_Elements, I have a query pulling the table & bidder info into UDE1 and UDE2. I isolated the queries separately as normal SELECT statements, and both pulled the correct respective information. Still nothing when printed.
Has anyone here used these procedures to print this type of information, and if so, is there a step I appear to be missing?
Thanks,
Anthony
Anthony,
You say the correct data is pulled from your select statements. Do you make sure to actually SELECT the output value (I think it is @ude_value) equal to that data, or are you just trying to select the data and have its output go to the ticket element? Been a while since I looked at our own LP_TICKET_ELEMENTS, but I think that procedure is set up with the output value specifically.
If you are doing that already, I would probably take Steve Wadey up on his offer.
John A. Moskal II
I copied the format of the existing examples, but getting eyes on it would be great. Here's what one of the queries looks like, the other is similar. It started simpler, but when it didn't work we'd tweak it slightly.
-- Return the value of a harcoded attribute for user defined element 1If @ude_no = 1 and @customer_no > 0 Select @ude_value = CAST(IsNull(key_value, '') as varchar(3)) From tx_cust_keyword Where customer_no = (SELECT recipient_no FROM T_SUB_LINEITEM WITH (NOLOCK) WHERE order_no = @order_no AND ticket_no = @ticket_no) and keyword_no = 514 --Gala Attribute from T_Keyword
Looking at that, I see nothing most obviously amiss, so at least there is that.
I pulled up what we have for LP_TICKET_ELEMENTS, and it looks like I apparently decided to always check that the sli_no = @cur_sli_no rather than relying on the ticket_no. Not sure why, but that might be worth trying; I suppose it depends when in the process the ticket_no is actually applied to the row in T_SUB_LINEITEM.
The IF statements for each @ude_no in our procedure also all have a check on the @design_type = 'T' (for ticket elements). Again, not sure why that would be NECESSARY, especially if you do not have anything hitting @ude_no = 1 elsewhere in your procedure, but might be worth trying. Also should not be necessary given your single statement after the IF, but I have gotten into the habit of putting BEGIN/END after every IF that is more than just one line, if for no other reason than to just keep things straight in my own mind and make sure I know when the IF portion ends.
The other interesting thing I notice is that, if there is no recipient given and/or the person does not happen to have that keyword attached to their account, that will return an empty '' string as you might expect but will only do so because it is declared that way at the procedure output parameter. Since there would not be even a single row left to evaluate whether or not something is or is not NULL, thus the CAST(IsNUll(key_value, '') as varchar(3)), so there is really no way for that query to ever return an empty string. Now, since the original declaration of the string is to an empty string (''), I believe it just does not even evaluate that at all and simply leaves it alone rather than setting it to anything. Again, not sure why that would matter here, but just something I noticed.
Hopefully that helps?
I'm with John on this - we've used @cur_sli_no in every custom element we've written.
In SSMS, you can try the following to see what (if anything) the SP is returning:
DECLARE @uv varchar(200)
EXEC LP_TICKET_ELEMENTS @customer_no={customer_no}, @design_type='T', @order_no={order_no}, @cur_sli_no={sli_from_order_no}, @ude_no={ude_no}, @ude_value=@uv OUTPUT
SELECT @uv
@design_type is required, even though you may not be referring to it...