We are belatedly gearing up for our V11 migration. We finally finished our RAMP migration a few weeks ago, and the various server upgrades required to host the V11 migration tools had not been done prior in anticipation of this, so I've only had access to them for a month or so (which included the conference and weeks focussed on the RAMP migration itself.
This leaves us with a very tight schedule for our V11 migration. I had hoped to work concurrently on managing the customization review while the power users I'd put in charge of scoping out the data migration strategy did their thing, but the bridge views that I expect to use heavily don't exist in V10, so I couldn't actually make or test any of the changes until at least our Test environment was upgraded to V11, and even then I was concerned about the amount of changes that would need to be made to the Live environment during the V11 upgrade itself.
However, after sleeping on it, it 's occured to me that creating the bridge views myself ought to be trivial (in V10 they're all just going to be a "select *" from the source table). And the V11 update would just drop all of the bridge views I created and replace them with the more complex versions that manage the V11 data.
Am I correct about this? That is 1) all the bridge views are designed to be identical to the old tables they reference (therefore my "select *" views will perfectly represent the Tessitura-provided bridge views) and 2) the V11 upgrade will cheerfully drop them in favor of the correct versions?
Thanks,
Gawain
FYI, I issued a TASK request on this as well, and the answers are Yes and Yes, so it looks like I'm good to go on this. Thanks Matt!
There are some changes you'll need to make which you can't really do in your Live database. For example, references to xref types will need to be replaced with new values for affiliations and/or associations.
What I usually do is make all the changes in a Test database and save the sql code as a file in a folder under User Reports, called V11 Customizations for example. Then after the upgrade, or a live to test copy, I open the files in the folder and execute them to make the necessary changes for V11.
David
Thanks for the note about XREF types. Another thing I'm seeing is lots of references to n1n2_ind where I will explicitly need to _not_ be looking at that in V11.
My strategy for these sorts of changes has been to create a T_DEFAULTS entry for version #. Then I pull that number in various stored procedures using FS_GET_DEFAULT_VALUE to generate a value I can used in conditional tests. I won't be able to test the new code until we have our Test db upgraded, but I can keep a single codebase operational in both environments. After V11 has burned in sufficiently I'll then go around and start removing those conditionals, hopefully.
I expect that T_DEFAULTS entry will come in handy again for V12...
--Gawain