Data-only Upgrade questions

[Alex_Pastuhov]

Cool, thanks, then I'm all set ;-)

 

[Jack_Crouch]

I hear you on the non-unicode of DTA and CTL. I assume you leave SY900, OL900, DD900, and SVM900 as unicode ("as delivered")? Or do you actually change this to non-unicode?

 

[Sanjiv Garg]

Hi Colin,

I have a question on #14 in you summarized plan, do you really need to reapply Update1/2 when re-running PD900 data-only upgrade plan since this was already applied when the PD900 upgrade (data-only) plan was ran first time?

Also I believe a data-only upgrade plan can be run multiple times by re-setting the staus of following to 30:

1. Table/Index Build Sts
2. Control Table Merges
3. Table conversion

Sanjiv

 

[cdawes]

The honest answer is that I've never bothered to fully look into the details but the Upgrade and Updates work based of change tables.

So if you're going Xe to 9.0 the change tables should take you to 9.0 and not 9.0.1 and not 9.0.2. This is why I believe that you need to apply the updates again.

Anyone who's had a few issues with the annoying Solution Explorer remerge after applying the updates to 1/2 the environments of on a subsequent conversion has likely run into this at some time or another.

If you look at the conversion history you'll see that Updates and abouth 1/10 or ESU's do a bunch of "stuff" other than just spec merge so unless you do it ............it's missing.

For a Data-Only upgrade I'm not sure why you'd use the same plan but I simply create a new plan whoch will grab the updated info from the latest Planner ESU that you may have recently applied.

Old Upgrade Plan = Old Conversion Sequence (unles you reload the TC Workbench)

For a Data only Upgrade you're missing a key step #4:

1. Table/Index Build Sts
2. Control Table Merges
3. Table conversion
4. Reset Environment Database Creation History


For all upgrades many new tables and indices are added. If you don't delete the history then these tables and indices are not recreated and the upgrade will likely fail.

Same situation for Updates applies for ESU's as well. ESU's can do Solution Explorer, UDC's, etc. If you're in doubt just reconvert an environment and compare it to one that you had converted and where you did apply the Updates and ESU's to. The easiest comparison is the UDC's ............you'll likely find a bunch missing.

This is why back in the Xe days so many environments got "hosed". You can't refresh an environment unless it's the same in terms of ESU's and Updates. Otherwise you need to REAPPLY any ESU's after first clearing that resetting the history.

This is one of the major issues I find on audits - it worked in PY but then it didn't work in PD or it was working and then after a refresh it doesn't work anymore.

I could be a little off - a lot of this is throey cause again I've never bothered to go that deep into the change tables so anyone can feel free to correct me if I'm off.


Colin

 

[Sanjiv Garg]

Thanks Colin for quick reply.

[ QUOTE ]
So if you're going Xe to 9.0 the change tables should take you to 9.0 and not 9.0.1 and not 9.0.2. This is why I believe that you need to apply the updates again

[/ QUOTE ]

It makes sense now why you recommend to apply Update 1/2 (without spec merge) after re-running data-only upgrade plan.

[ QUOTE ]
Anyone who's had a few issues with the annoying Solution Explorer remerge after applying the updates to 1/2 the environments of on a subsequent conversion has likely run into this at some time or another.

[/ QUOTE ]

I believe you mean by P9848 record.

[ QUOTE ]
For a Data-Only upgrade I'm not sure why you'd use the same plan but I simply create a new plan whoch will grab the updated info from the latest Planner ESU that you may have recently applied.

[/ QUOTE ]

Makes sense why to create new upgrade plan when new planner ESU recently applied.

[ QUOTE ]
For all upgrades many new tables and indices are added. If you don't delete the history then these tables and indices are not recreated and the upgrade will likely fail.

[/ QUOTE ]

I believe #1 Table/Index Build Sts (Environment) does this automatically. When you reset the environment Table/Build status, environment workbench runs to create new tables and indices part of your upgrade and will report any indices which will be created during conversion workbench.

[ QUOTE ]
Same situation for Updates applies for ESU's as well

[/ QUOTE ]

So you mean to identify ESU's in F984052 (!=R98700) that touched the Business data and Control tables for that environment and apply them without spec merge.

 

[aniket12323]

Hello Dear Ones,

After reading this thread, I understand that I was missing P984052, P984072 parts totally from my PLAN.

Thanks a ton Appreciate your great detailed Analysis and Thanks for A2A.

Cheers!!!