Just after our V11 upgrade I'm getting this error on a couple of reports. Has something changed with Tessitura control group security that I've missed or forgotten about? The parameter in common to the reports having this error involves pulling a list of post_nos and checks against VRS_BATCH_TYPE. The parameter pull downs are fine in the client, but I observe that selecting directly against that table as dbo returns no results: perhaps the initial pull of data happens in the context of the client user, but then immediately control is passed over to ImpUser or the like, and ImpUser no longer has access to those rows in TR_BATCH_TYPE?
Any clues or suggestions would be appreciated,
Gawain
When the Report Parameters window is loaded, the parameters for the user’s last report request are used to preset the parameter values. If the SQL can’t be constructed properly this error message can be the result. I would look at the last run request for your user/usergroup, get the request id (gooesoft_request.id) and you can try running this procedure to see the results:
Exec AP_GET_PARAMETER_VALUES @request_id = ####
You can also see this executed by running a trace in Profiler while opening the report parameters window.
+Ryan Creps
+Tessitura Network
From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Gawain Lavers Sent: Tuesday, March 12, 2013 1:49 PM To: Ryan Creps Subject: Re: [Tessitura Technical Forum] “Error retrieving parameter set for [report name].”
Hmm. Thanks for the suggestion: I'll pass it along to support.
From: Caryl Jones <bounce-caryljones3976@tessituranetwork.com> Sent: 3/12/2013 3:53:37 AM
I had the same error on a report and the only way I managed to fix it was to take a copy of the Report Set Up file and then use the new version instead of the old one and suddenly the report worked without any issues at all.
Caryl
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!
Sorry Ryan, Karen actually helped me fix this on TASK, and I've been so overwhelmed with other post-V11-upgrade tinkering I forgot to write the coda here.
Turns out we were being a little to clever in the report setup. There was basically one report/stored procedure, but it could take either a set of batch numbers or a single posting number. We used the same view to generate entries for either menu, but in the latter (posting) menu, we had incorporated a "Group By post_no" into the "Where" column of the report setup in order to not have large numbers of repeated posting numbers.
That apparently worked fine in V10 (or maybe SQL 2000?), but doesn't work now. I build a new view geared towards presenting posting numbers, eliminated the "Group By" from the "Where" column, and everything worked fine.
Actually, that's a lie, I'm still trying to get the report to provide the right data, but the report runs, and that's a start....
Thanks,