For those migrating soon, what’s your migration date?
We are T-minus 17 days – Sunday October 7
Gonna start working on my migration-day procedure sheet!!
Dave Vivino
Cleveland Orchestra
What sort of difficulties are you having>? I could always learn!
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Beth Hawryluk Sent: Wednesday, September 19, 2012 9:33 AM To: Joe Giambalvo Subject: Re: [Tessitura Next Generation Forum] What's your Migration Date?
No specific date for us yet. We've been trying to upgrade since June but having too many technical difficulties!
Well our test system is upgraded - which makes things interesting. :)
Good luck to you guys! May your migration be smooth sailing.
From: David Vivino <bounce-davidvivino4732@tessituranetwork.com> Sent: 9/19/2012 10:17:17 AM
You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!
Oh what issues HAVEN'T we been having? :)
Our big issue right now is a problem with SSRS. We were actually having an issue with it prior to the upgrade attempt but we thought the issue was specifically with our custom SSRS reports. Turns out it isn't! Now that we've upgraded to V11 in Test we can run these reports only if we are logged directly into the Test server. If we try to do it from a desktop machine or via the web we get script errors and nothing will display. My IT support has spent hours going through our security and policy settings and can't find anything that would be causing this issue. We've even stumped the Support team! But it needs to be resolved before we upgrade as a few of our daily custom reports are SSRS. In V10 we had a work around but that solution doesn't seem to work in V11 for some reason.
We'd hoped to start with Test a couple of weeks ago, but eventually realized that was fantasy: we had only just completed our migration to RAMP, or rather hadn't completed it (there wound up being a few kinks to work out). I'm hoping the fact that we have gone to RAMP will spare use the back end configuration difficulties, but naively the migration tools have made the process seem pretty easy, if time-consuming. We're currently not scheduling anything, just working on it as we have time, but would like the transition to happen before the end of October.
I tasked a handful of our power-users with the constituent mappings while I've attacked the customizations. I think they're largely done at this point, so much of the onus is on me. My biggest concern with the customizations (had about 60 odd issues flagged by the Customizations Review report) was having to make so many coding changes right in the middle of a major upgrade. I have two tips for that:
1) I created a SQL function that pulls from a T_DEFAULTS value I call "Tessitura Version". Now I can just drop that in anywhere I feel that code needs to behave differently in V10 vs. V11.
2) I went ahead and created all of the bridge views in Version 10. In V10, of course, the view just selects directly from the table or view it's supposed to duplicate in V11, i.e. my version of VB_CUSTOMER just pulls "select * from T_CUSTOMER". Now I can recode my customizations that I expect to rely on the bridge views in V10 and expect them to behave exactly the same when the views are replaced with the actual bridge views in V11.
These two things mean I can address most of my mitigation issues and have working code in V10, then without changing code update Test to V11, and hypothetically my testing of those features in V11 ought to show no issues, or at least relatively few.
--Gawain
Beth did you get these resolved? If so can you give me a an idea what the problem was?
Hi John!
We've figured out what the problem is but have not found a real solution to it yet. The long story short is it is a group policy setting preventing users from running the reports.
On a select group of users that frequently run these reports we have removed several of their group policies so they are able to run them. All other users must ask someone else to run any SSRS reports as they are needed.
It's not ideal but we have no idea which policy is preventing this process. Our group policies were set up by an IT person that no longer works here and they are extremely intricate.