Skip to main content
avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
January 6, 2025
Solved

Results of Single Level Version Conversion Utility

  • January 6, 2025
  • 3 replies
  • 1631 views

I wrapped up my questions to PTC with utility "works to specification" which is not the deep level of understanding I was hoping for, I was assured that things like purging and deletion would be unaffected but I want to test that to be sure or at least document them. @Marco_Tosin, let me know if you've seen anything odd since you said you ran this before me. 

Here is what I wanted to document. In our use case, all MFG views were created from the Design view using "New View Version". We never revised from the MFG view downward.

avillanueva_0-1736201572042.png

I am sure the conversion had to make some compromises for other use cases but the database does record the predecessor version in its tables showing it came from the Design view in each case. Post conversion, except for the first version of the MFG view, all now show as revises. 

avillanueva_2-1736201744068.png

While the predecessor version was altered, as mentioned in my previous post, the iteration that the version was created from was retained showing the Design version. The database records somewhat disagree with each other. PTC indicated that this was ok and should not impact integrity and functionality. I have to their word for now but I will close with some testing results. I just wanted to clearly document things for others though I expect I am a behind the curve on this one. 

 

 

 

 

Best answer by avillanueva

Closing out this thread with my final notes. We ended up successfully applying version letter changes to meet goal of aligning the MFG version to the Design version it was "derived" from. Found a couple of stragglers but all clear. Next we moved on to keeping things in sync. One solution was to prevent users from revising MFG view version. This can be done by a filter on the action but does not catch all cases like revising from change tasks and multi-object revisions. We could continue down the filtering avenue but we employed a listener on NEW_VERSION that catches all and throws a WTException. Action filters do provide a better, up front user experience. 

Our logic works like this: Goals is to allow a one time only action from Design to create a New View version to Mfg from any specific Design version but that must be done in order. Our series goes from -, A, B, etc. There are two conditions the listener checks on:

  • What is the version of the MFG to be created? Does it equal "-" or first version? (X)
  • Second case is does the MFG version being created match the version letter of its predecessor Design view version? (Y)

From here we can construct the following truth table:

X Y X OR Y Resulting Action
T T T Ok - Do nothing
T F T Ok - Align Versions
F T T Ok - Do nothing

F

 F F Throw Exception

Check condition Y first and if true, no action needed. If X is true, align version. If X is false, throw an error since this would case Design and Manufacturing to get out of sequence. To align the versions, I will link back to this thread:

Set Revision API is failing to set same Revision for Manufacturing View Part and Design part. 

We had to use a different method, similar to updateVersionIdentifier by taking the version identifier from the Design View and applying to the Manufacturing View and PersistenceServerHelper.manager.update for both the Part and ControlBranch.

3 replies

Marco Tosin
21-Topaz I
Marco Tosin21-Topaz I
21-Topaz I
January 8, 2025

@avillanueva 

we did just this morning the migration of data from the current 12.0.2 test server to the new 13.0.2 test, with the modified single-level revision scheme.

 

I have talked to my consultant about what you wrote above, to see if we can give you some information of how we solved the problem you report.

 

As soon as possible I will post what we can share that might be helpful to other users as well.

 

 

Marco
    avillanueva
    23-Emerald I
    avillanueva23-Emerald IAuthor
    23-Emerald I
    January 8, 2025

    Lost me on the first part. Is your production system passed this conversion and on 13? I am thinking my only path forward is after the conversion is complete is to run SQL updates to shift the revision letter forward which should not impact much, Its just a text field. Goal is to keep the Design View and Mfg View revisions in line. 

    Marco Tosin
    21-Topaz I
    Marco Tosin21-Topaz I
    21-Topaz I
    January 8, 2025

    We have just started the activity for the upgrade.

     

    This morning we completed the migration of data between the test systems.

     

    Into production with version 13.0.2, if all goes well, we should go in early June.

     

    Bear with us for the more detailed response but we are working, even now, to complete the installations on the new test server of the various connectors of the systems connected to Windchill.

     

    Marco
    avillanueva
    23-Emerald I
    avillanueva23-Emerald IAuthor
    23-Emerald I
    January 15, 2025

    Just providing some updates on this topic. I completed a second conversion and ran the query I posted as solution here:

    https://community.ptc.com/t5/Windchill/Single-Level-View-Version-Conversion-Deprecation-and-warning/m-p/985989#M83123

    This shows me what the versions need to be to align with Design View. I was able to reduce that to just updating by branch ID to sets of these updates scripts in this form:

    UPDATE WTPART SET versionida2versioninfo='B' WHERE BRANCHIDITERATIONINFO=1153919464;	
UPDATE CONTROLBRANCH SET VERSIONID='B' WHERE IDA2A2=1153919464;

    12K lines later its complete with a few zone constraint violations. I needed to make sure I run them from latest version backward. Can't have two branches with same letter. Spotted some errors that I was able to manually correct but its done.  Next on to some code updates to block revising in certain conditions. 

      avillanueva
      23-Emerald I
      avillanueva23-Emerald IAuthorAnswer
      23-Emerald I
      January 23, 2025

      Closing out this thread with my final notes. We ended up successfully applying version letter changes to meet goal of aligning the MFG version to the Design version it was "derived" from. Found a couple of stragglers but all clear. Next we moved on to keeping things in sync. One solution was to prevent users from revising MFG view version. This can be done by a filter on the action but does not catch all cases like revising from change tasks and multi-object revisions. We could continue down the filtering avenue but we employed a listener on NEW_VERSION that catches all and throws a WTException. Action filters do provide a better, up front user experience. 

      Our logic works like this: Goals is to allow a one time only action from Design to create a New View version to Mfg from any specific Design version but that must be done in order. Our series goes from -, A, B, etc. There are two conditions the listener checks on:

      • What is the version of the MFG to be created? Does it equal "-" or first version? (X)
      • Second case is does the MFG version being created match the version letter of its predecessor Design view version? (Y)

      From here we can construct the following truth table:

      X Y X OR Y Resulting Action
      T T T Ok - Do nothing
      T F T Ok - Align Versions
      F T T Ok - Do nothing

      F

      		 F F Throw Exception

      Check condition Y first and if true, no action needed. If X is true, align version. If X is false, throw an error since this would case Design and Manufacturing to get out of sequence. To align the versions, I will link back to this thread:

      Set Revision API is failing to set same Revision for Manufacturing View Part and Design part. 

      We had to use a different method, similar to updateVersionIdentifier by taking the version identifier from the Design View and applying to the Manufacturing View and PersistenceServerHelper.manager.update for both the Part and ControlBranch.

        HelesicPetr
        22-Sapphire II
        HelesicPetr22-Sapphire II
        22-Sapphire II
        January 24, 2025

        Hi @avillanueva 

        Good work. 

        Thank you for sharing your experience. It is very useful knowledge. 

        PetrH

        HelesicPetr
        22-Sapphire II
        HelesicPetr22-Sapphire II
        22-Sapphire II
        January 20, 2025

        Hi @avillanueva 

        Have you got any information, why this schema is going to be rid of ? 

        I would like to hear any real reason from PTC but it is as a gramophone . They still repeat "Works to product specification" :D. 

        PetrH

        avillanueva
        23-Emerald I
        avillanueva23-Emerald IAuthor
        23-Emerald I
        January 20, 2025

        Which schema? Do you mean support for multi-level versioning? No, I will ask at the conference but its likely the decision was made along time ago. I suspect it had something to do with MPMLink and tools to sync between the views. Its is a simpler structure. All I know is we will see a rash of posts on this as users move to 13 since its now a requirement to upgrade.

        HelesicPetr
        22-Sapphire II
        HelesicPetr22-Sapphire II
        22-Sapphire II
        January 20, 2025

        @avillanueva 

        Yes, the multi-level schema. 

        You right 😄 it depends on how many companies use the multilevel versioning schema.

        In our region, there are not so many companies that use it.

        PetrH  

         

        Terms & ConditionsAccessibility statement