Hello HomerJ,

Every time I have seen issues related with version control after the upgrades like this, the only way to resolve it (and the recommendation) is to disable/turn off the version control and then to re-enable the version control (in fact some of the older upgrade guides even recommended turning off VC in the original ALM version prior to attempting upgrades to avoid the checked out issues and re-enabling VC after the upgrade was completed).  The problem is that doing this can erase and delete the history for the various entities.  Of course you get no other option due to the nature of doing an in place upgrade and having no way to deal with the pre upgraded versions without jumping through lots of hoops and lots of work.

Short of a full recovery of the project (repository for the project and DB schema for the project) there is no way to restore the requirements.  If you had backups of the individual repository and its related project schema it would be possible to restore that project and get the requirements and drag them across to the current project however all linkages and coverages would be lost as the requirements would have new numbers (and if coverages and linkages existed they would haver to be recreated).  This is the reason I was pushing to have the backups already taken and available and a condition I warned of.  Once a version is checked out and the check back in isn't done but instead the VC entries are cleared, then the version reverts to the last known good version and if none existed then it is lost.  Unfortunately this is the design of the system.

Clearing all of the version control tables and disabling and then re-enabling the version control is really the only way I have heard to rectify the situation when rolling back is not an option.

Dan