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
Im Not in today so can't check our setup. If you think its a security issue, if you have access to management studio, right click the table and click properties. There is a security tab on there. Click this and see if impuser has select access.
I would expect an error instead of no results returned.
What error are you getting as I cant see an attachment here.
How are you querying the table? Directly through management studio? What's your query syntax (just copy and paste what you're typing)
Wayne
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
Gawain,
I would definitely check the security permissions as Wayne suggested. Particularly on any local views or tables that are involved. It was sporadic, but after the last V11 upgrade I went through, there were a few objects in the database that no longer had ImpUsers assigned to a role.
If that isn't the case, the next thing I would check would be gooesoft_request_parameter for the particular report request to see if perhaps one of the parameter values is being inserted there in a way that makes a select against it fail.
Hmm. Thanks for the suggestion: I'll pass it along to support.
So, for my view, VRS_BATCH_TYPE, VRS_BATCH_TYPE_GROUP and the table TR_BATCH_TYPE_GROUP, all have Impuser/Database role with at least select permissions. The table TR_BATCH_TYPE also has Tessitura.app in an Application role: none of the others do.
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].”
From: Caryl Jones <bounce-caryljones3976@tessituranetwork.com> Sent: 3/12/2013 3:53:37 AM
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,