WINDU Issue "CheckoutConsistencyReportDT"

[Mat]

Version: Windchill 12.0

Use Case: WINDU Issue "CheckoutConsistencyReportDT"

Description:

Hi there,

I ran WINDU and ran into a "potential problem" named "CheckoutConsistencyReportDT".
In cs350652 there is a "solution" to alter the corresponding values in the data base.
https://www.ptc.com/en/support/article/cs350652

It says "Manually update ida3a2ownership and classnamekeya2ownership column values to 0 & null for the problematic entries". But in which table? And how do I find the entry to change?

If I run this in the database, I get 114 results. This means, that there are 114 tables with those columns.

select *
from INFORMATION_SCHEMA.COLUMNS
where COLUMN_NAME like 'classnamekeya2ownership'

So, how to fix the CheckoutConsistencyReportDT problem?

PS: I tried to send a feedback for the article, but the "feedback feature" does not work.

[mmeadows-3]

You need to log a call and work with PTC Tech Supt to appropriately address this one.  The SQL queries to fix it vary based on the functionality being used: projects, family tables, etc.  I've been through this a few times and still don't have a clean, reliable process for analyzing and cleaning up these issues.

[avillanueva]

It depends upon what object reported issues. If it was Parts, then it would be the WTPart table. Might also be the ControlBranch table. The 114 would represent how many rows had issues but that can be spread to a number of tables that deal with objects that can be checked out. CAD data and documents are other types. Agree with @mmeadows-3, best to work with PTC. Backup DB before making any manual changes or running fixing scripts. 

[Mat]

Sorry, I had to be more clear. We really do not use WTParts in our company (licences are too expensive for us).

The report gives me a couple of Creo-parts (about a dozen), like this

Thu 7/10/25 13:39:05: ============================================================================================================================================
Thu 7/10/25 13:39:05: Inconsistent Ownership status detected ( total : 14 )
Thu 7/10/25 13:39:05: ============================================================================================================================================
Thu 7/10/25 13:39:05: | Object  Id                                                                                         |    Checkout Status |
Thu 7/10/25 13:39:05: ---------------------------------------------------------------------------------------------------------------------------------
Thu 7/10/25 13:39:05: |EPMSep Family Table - cad_22000197.prt                                                              |                 c/i|
Thu 7/10/25 13:39:05: |EPMSep Family Table - cad_20009453.prt                                                              |                 c/i|
...

strangely, the report mentions "Familiy Table". But most of those parts do not have a family table.

Oh, and backing up database before editing is mandatory. How crazy would You have to be, without doing so? 🙂

[avillanueva]

Without seeing the full list of objects, it could either have an issue with the EPMDocument table or as shown above the EPMSEPFAMILYTABLE table. I checked the last one and the columns listed in the article are shown. The trick is getting the rows based on the object number which is stored in the EPMDOCUMENTMASTER table. For EPMSEPFAMILYTABLE, it also stores names so assuming this is your offending table, you could run a query like this:

SELECT m.name, t.ida2a2, t.ida3a2ownership, t.classnamekeya2ownership
FROM epmsepfamilytable t, epmsepfamilytablemaster m
where m.IDA2A2 = t.ida3masterreference and
m.name like 'nas0620.prt'

The IDA2A2 is a unique row entry it most tables so this will give you the exact rows in the EPMSEPFAMILYTABLE that its complaining about. then you can follow the steps in the article to change those values to 0 or null. I would start with 1 entry then rerun the report to see if it drops by one.  

If you are good a SQL, you can likely create an update script based on the query above and feed in all the items reported by the windu check and update all at once. Note, the same query modified for EPMDocument and EPMDocumentMaster should work for those tables. 

[Mat]

Thanks for that, I will give it a try as soon as possible.