How can I find out if I have checked out entities within projects in QC/ ALM?

  • Questions
  • How can I find out if I have checked out entities within projects in QC/ ALM?
Question ID: 105046

I am getting ready to upgrade my projects to a newer version and was wondering how I would find out if checked out entities still remain within the projects to be upgraded?

Marked as spam
Posted by (Questions: 379, Answers: 35)
Asked on July 9, 2013 4:13 pm
Answers (3)
Private answer

HI HomerJ,
Makes sure that when upgrading a project with versioning enabled, all of the entities must be checked in before the upgrade as a project with checked out entities will get a failure during the Verify-Repair process of the upgrade.

To ensure that the project has all entities checked in, run the following SQL statements on the project from the site administrator:

SELECT COUNT(*) FROM VC_BPM_MODELS (For 11.00 and 11.52)

If any of these queries returns COUNT(*) > 0, then checked-out entities exist. In that case, go to the project to be upgraded and check in all the entities that are checked out or use ''undo check out'' (use this as a last ditch option as all changes made will be lost and the entity will be reverted to the last known version). Re-run the SQL statements above again and repeat until COUNT(*) = 0 is returned and now the project is ready for upgrade.

I hope this helps,

Marked as spam
Posted by (Questions: 0, Answers: 770)
Answered on July 9, 2013 4:23 pm
Thanks for the information. That is exactly what I was looking for.
( at July 9, 2013 4:23 pm)
Private answer

I'm on a project team and we're currently trying to upgrade from HPQC 11.0 to 11.5 (once that's all sorted out and stable, we intend to move on to 12.0). We can't afford risking downtime with the production server, so we're using a new server (these are all VMWare VM's) for the new QC. The current Prod is Win 2003, the 11.5 is Win 2008 and the 12.0 will be Win 2012.

The procedure we've been using is making a clone of the database, copying over the repository and editing the db server and file location lines in the dbid.xml files. That works and we can restore projects in the new server. The problem we having is when we try to upgrade a project, we get that error stating there are checked-out files that require manual intervention.

I was hopeful we had the solution after I found this post yesterday. There were a fairly large number of old checkouts that showed up in the five tables listed above, and we got all of that stuff checked back in and all five tables are now empty. However, after deactivating all projects, making new copies of the database and repository, reinstalling QC on the new 11.5 server and restoring just the one project we're primarily using, we're still getting the checked-out items error when we try to verify the project.

Our users need to retain versioning, so turning it off to get past this error is not a viable option. Any ideas on what we should try next?

Marked as spam
Posted by (Questions: 0, Answers: 1)
Answered on November 14, 2014 2:43 pm
Private answer

The five tables listed are not a complete list of tables that store version control information. In v11.52 there are a total of 30 tables that can hold VC information. If you go to Site Admin, the Site Projects tab, and expand an individual project you will see the full list of data tables in that project. The ones that store version control information are named with VC_*. If any of those tables have records, then Verify will report there is checked out information.

The five tables listed are the main tables. VC_TEST lists checked out test cases. If you checked them all in, then that process should've cleared the other associated Test tables - VC_TEST_CONFIGS, VC_TEST_CRITERIA, VC_TEST_MULTIVALUE, VC_TEST_PARAMS, and VC_DESSTEPS. But check all the tables to find out what is still checked out.

Marked as spam
Posted by (Questions: 1, Answers: 101)
Answered on November 14, 2014 7:05 pm
Thanks Trudy! I did end up looking through all the other VC_ tables later this morning and found some other checkouts in VC_ASSET_RELATIONS and VC_ASSET_REPOSITORY. Looks like those checkouts got auto-created by a workstation app a user had been using. I'm going to have to wait for him to reinstall that app before he can get the stuff checked back in. Hopefully we'll be good to go once that's done. :) Mike
( at November 14, 2014 9:55 pm)
OK, so unfortunately, it looks like all the client-side checkout info was lost when the user uninstalled his app, and he has no discernible way of checking these 11 files back in. As best we can determine, they are not files that will be used in any way in the project going forward. Would it be feasible to just delete their entries from the VC_ASSET_RELATIONS and VC_ASSET_REPOSITORY tables, since we don't expect the files to ever come into use again?
( at November 17, 2014 8:08 pm)