Greetings all,
I hope there is something I am missing here. We recently upgraded to 15.1 and I am now having cases where the built in salutation elements are causing my outputs to fail because they are pulling more than one row for certain constituents. According to the documentation, this isn't supposed to be possible with the virtual tables. Is there a system table update or setting somewhere that I need to adjust? I am very close to having to inactivate those elements and replace them with custom coded ones, but I don't want to do that with basic Tessitura options.
Any assistance would be greatly appreciated.
Thanks!
One possibility is that the unique constraint is not being imposed by the database, but by the application. In such cases, it is possible for bugs (or improperly-written customizations) to circumvent the constraint and cause you to end up with multiple salutations of the same type per customer.
What you probably want to do is isolate the specific issues and then devise a query to audit your database for those issues. This may help you understand where the issues came from (a bad import, perhaps?) or to issue a corrective update to bring the database in line with what is expected by the application and output set elements.
Thanks Nick,
I think my challenge right now is that I'm not sure what that virtual table uses to pull the data. When I look at one of the constituents that is having issues, I don't see any obvious problems so it is hard to know where the element pull is going wrong. I would have thought this table would use the "primary" parameter to select the salutation, but since there issue happens with constituents who only have one primary, that doesn't seem to be the case. Does anyone know what that virtual table pulls from?
Yeah, the "virtual table" is a big amalgam of temp tables and dynamic SQL inside of RP_RUN_QUERY. The data itself is stored in TX_CUST_SAL.
The key to troubleshooting this kind of thing is being able to work your way backwards through the Tessitura code so that you can reproduce the problem consistently with your own query in SSMS. This can be challenging, but is also incredibly instructive when you figure it out.
Thanks Nick! Knowing that this comes from RP_RUN_QUERY is really helpful. Hopefully I can work out some SQL to get to the bottom of this now.
Thanks Again!