Skip to main content
avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
November 27, 2024
Solved

Single-Level View Version Conversion Deprecation and warning

  • November 27, 2024
  • 2 replies
  • 1843 views

Blast from the past has kicked me in the "ast".

 

Glad I am reading 12.1.2 What's new. So, I've had my system running since Windchill 7. At that time view versions used a multi-level version schema (A.A, A.B, etc). While I've known about the new default for single level and this utility for sometime, it was never on my near term to-do list to convert. I am now jumping to version 13.0.2 so am I hosed? I know deprecated does not mean gone but if I have to do this before I upgrade, I need to get it done now.

https://www.ptc.com/en/support/article/CS414044?source=search

Just search and found this. Ok, not hosed but let's run a test on my test server. The process was very straight forward, documented here: Running the SingleLevelViewVersionConversionUtility Command Line Utility It generates scripts by context (Project, Product, Library and Org) where you can convert all parts versions with multi-level view versions to single-level. What was B.- should become B.  Process took about 45 mins to run all areas and convert 33K versions, zero errors but I recommend running the WinDU scripts InvalidSeriesValues, RevisionLabelCleanserDT, SeriesSortDiagnosticTask and RevisionSequenceCleanserDT just to make sure you are error free first. 

 

Here is the real kick in the teeth. We have a number of Part versions that were loaded in via imports that did not start with our first version letter of - (Dash). Say I started life at version E and created a new view version off that which became E.-. Same would follow when I revised to F, becoming F.- for the Manufacturing view. Here is an example of what I expected and what happened:

Number versionInfo.identifier.versionId Expected New Version Resulting Version
PartXYZ E.- E -
PartXYZ F.- F A
PartXYZ G.- G B
PartXYZ H.- H C

I understand why it did what it did and some of the complexities that had to be handled (What if I had E.A and E.B existing?) but boy did this create a mess. Glad it was on Test server and not production. Still, 26% of the revisions are not what I would consider correct (where version of Manufacturing view matches version of Design view it was derived from). I am not expecting that someone has a ready made solution for this legacy issue but if you do, please reply. I expect to be writing a large SQL query to clean this all up and be ready to do this for my production system when I convert it. Happy Thanksgiving all.

 

Best answer by avillanueva

Ok this query worked better.

SELECT P3.IDA2A2 "PART ID", P3.BRANCHIDITERATIONINFO "BRANCH", m3.wtpartnumber "Part Number", p3.versionida2versioninfo "Part Rev", p3.iterationida2iterationinfo "Part Iteration",P3.IDA3View "Part View", pred."Predecessor Rev" "Correct Rev"
FROM WTPART P3, WTPARTMASTER M3,
(SELECT P.BRANCHIDITERATIONINFO "BRANCH", m.wtpartnumber "Part Number", p.versionida2versioninfo "Part Rev", P.IDA3View "Part View",P.IDA3E2ITERATIONINFO "PRED ID", p2.versionida2versioninfo "Predecessor Rev", p2.iterationida2iterationinfo "Predecessor Iteration", P2.IDA3View "PRED VIEWID" 
FROM WTPART P, WTPARTMASTER M, WTPART P2
WHERE
p.ida3masterreference = M.IDA2A2 AND
p.ida3view = 1447 AND
P2.IDA2A2 = P.IDA3E2ITERATIONINFO AND
p2.ida3view = 1445 AND
NOT(p.versionida2versioninfo = p2.versionida2versioninfo)) PRED
WHERE
p3.ida3masterreference = M3.IDA2A2 AND
p3.ida3view = 1447 AND
P3.BRANCHIDITERATIONINFO = PRED.BRANCH

 I have to take a serious step back but it looks like they left IDA3E2ITERATIONINFO the same which is the true iteration the Manufacturing view was branched off of. Should be easy enough to correct the letter and sortid. Also need to correct the CONTROLBRANCH table but more investigation needed.

2 replies

HelesicPetr
22-Sapphire II
HelesicPetr22-Sapphire II
22-Sapphire II
November 28, 2024

Hi @avillanueva 

Do you think that direct change in database can solve your issue?

I did statebase versioning change from alphabet revision to number revision. 

I know it is not supported but it is possible to change existing data from one statebase versioning schema to another. 

If the sql script and a steps how to process would help, I will send it you. 

PetrH

 

avillanueva
23-Emerald I
avillanueva23-Emerald IAuthor
23-Emerald I
December 9, 2024

Just getting back from vacation. Yes, I think the solution is a direct DB change. If you can send the SQL, it would help as I want to make sure this is "correct".  I do not think that I am alone in how I see versioning working. We do use view version but see versions locked and synced (one version for the part). The way this seems to work allows Design view and Mfg view to differ and depart from one another. I would like to prevent that and have ideas as to how. 

HelesicPetr
22-Sapphire II
HelesicPetr22-Sapphire II
22-Sapphire II
December 10, 2024

Hi @avillanueva 

Here is the SQL to update existing revision schema.

versionIdA2versionInfo is the revision character that you need to change and you have to repeat this update for all characters one by one. 

versionSortIdA2versionInfo is a sort ID where is saved the order of the characters. 

I set it versionSortIdA2versionInfo  to a "sortId" string because after this update I recreate the sortId by RevisionLabelCleanser 

UPDATE
 [wcuser].[wcuser].[EPMDocument]
SET
 [wcuser].[wcuser].[EPMDocument].versionIdA2versionInfo = '1',
 [wcuser].[wcuser].[EPMDocument].versionSortIdA2versionInfo = sortId
FROM
 [wcuser].[wcuser].[SeriesSortValue] AS SeriesSortValueTable
 INNER JOIN [wcuser].[wcuser].[EPMDocument] AS EPMDocumentTable
 ON SeriesSortValueTable.[value]='1' AND SeriesSortValueTable.uniqueSeriesName= 'wt.series.HarvardSeries.StateBased'

WHERE EPMDocumentTable.versionIdA2versionInfo = 'A';

after all database updates run a Windchill shell function

java wt.vc.RevisionLabelCleanser -update

this correct all sortId values. 

also here is a sql to change the schema from HarvardSeries to StateBased

update wcuser.wcuser.EPMDocumentMaster
SET series='wt.series.HarvardSeries.StateBased'
where series='wt.series.HarvardSeries'

Hope this can help

PetrH

Marco Tosin
21-Topaz I
Marco Tosin21-Topaz I
21-Topaz I
November 28, 2024

We set up our own new test servers with the same version of WNC currently in use (12.0.2) to check conversion times, and after three or four iterations due to some exceptions to be handled, we had the results after 6 hours.

 

We do not have a purely literal revision scheme, like the example you gave, but an alphanumeric one (e.g., A1.1 for WTPart and EPMDocument or 0.1 for WTDocument ) and we noticed that, if in the three-level scheme only the last one (which corresponds to the plant view) is changed, the version resulting from the conversion sums the values.

 

Example: starting with A1.A0.A0 (Design.Mfg.Plant) and revising only Plant becomes A1.A0.A1, in the new schema the conversion sums Design+Plant and thus becomes A2.

 

Marco
Terms & ConditionsAccessibility statement