Skip to main content
S
SuperVaughn1-Visitor
1-Visitor
February 3, 2020
Solved

Modification of State Based Revision scheme

  • February 3, 2020
  • 3 replies
  • 4872 views

Hello,

 

We are looking into migrating our next location into Windchill and have a versioning issue. Our HQ uses Numeric prior to Release and Alpha post Release, hence WC is configured this way with state-based revisioning. The next location uses Numeric for Released revisions.

 

We are being told, by PTC there is concern about corrupting the database.

1. We cannot modify the existing XML state-based sequence. 2. We cannot create a new sequence for an existing object (load new named XML file).

  Has anyone any experience with modifying the state-based sequence in anyway?

We are considering Importing the data in at the Numeric revision, but Released state. This violates the State Based sequence.

 Has anyone tried that?

Or we are considering adding a "-" to preceed "A" for Released.

  Has anyone had success with ADDING a value to Sate Based revisions?

 

Thanks for your response.

 

Best answer by TomU
@MikeLockwood wrote:

... have to verify thru testing whether ... an earlier seed can be invoked after a later one has been used.

It's been a long time since I tested this, but my experience in the past was that it is only possible to revise 'down' the list, regardless of the series.  Adding new values further up the list wasn't a problem, but these new values don't have any impact on existing objects that are already below them.  Of course newly created objects can start anywhere on the list.

 

By the way, it is possible to put the dash ("-") before either the numbers or the letters, but it can only be listed once in the file (like Mike stated.)  Any of these series would be fine:

 

-

1

2

3

A

B

C

 

(or)

 

-

A

B

C

1

2

3

 

(or)

 

1

2

3

-

A

B

C

 

(or)

 

A

B

C

-

1

2

3

3 replies

J
JHall1-Visitor
1-Visitor
February 3, 2020

@SuperVaughn 

I've heard of this request before.  It seems somewhat common that companies use a numerical versioning scheme prior to Release, and Alpha after Release (or vice versa).   I have never heard of a solution from PTC, but would be happy to learn of one.

James 

Windchill 11.0 M030 CPS16

B
23-Emerald III
BenLoosli23-Emerald III
23-Emerald III
February 3, 2020

You can only modify a revision table file IF the mods are placed AFTER the last used entry that has been used in the existing table.

You may be able to add a new scheme at the end, but this would require a second set of Lifecycles to use this revision scheme.

You may NOT add a '-' before the 'A' revision. That will corrupt the revision sequencing.

 

S
SuperVaughn1-VisitorAuthor
1-Visitor
February 3, 2020

Thank you for the response Ben. What are your thoughts on the other comments in this thread? PM if you like.

M
22-Sapphire I
MikeLockwood22-Sapphire I
22-Sapphire I
February 3, 2020

Not a problem at all - have done this multiple times.

1. Can add a section to the stateBasedVersioning.xml file at any time as long as the Revisions are unique (cannot re-use Rev A). This can be tricky, but if adding a numeric series before the letters, can be made to work.

2. Sequence defined in the xml file and loaded to the database can be utilized differently by product/library context.  In one Product for example, can set all data to start with Rev 1, 2, 3...the A, B, C when ready while in another Product, all data starts with Rev A, B, C.

3. For the situation described (use the reverse, letters, then Numbers (common in Europe)), have to verify thru testing whether thru the lifecycle selection of NUMERIC / MILSTD for each state that an earlier seed can be invoked after a later one has been used (e.g. Revise from Rev B to Rev 1).  I haven't actually tried this but believe it can be done.  I may try this at home tonight.  May in fact not be possible but worth having some facts.

 

If PTC said it would corrupt the database, they are likely being very cautious on this - worth testing thoroughly on a rehosted non-prod system but should be possible. Cannot recover from putting this in place and continuing work if in fact it can't be done.

 

Note that the xml file is just a way to load the database - it is not "read" except when loading to the database.

Key thing is calling the first Revision of each seed via Revise in the lifecycle configuration.

 

Note: May need to clear all data from the versionseriessortid table and command it to be repopulated.  In the same system, Rev A is after or before Rev 1 for data depending on the context.  Cannot move the data because of this of course.

T
23-Emerald IV
TomU23-Emerald IVAnswer
23-Emerald IV
February 3, 2020
@MikeLockwood wrote:

... have to verify thru testing whether ... an earlier seed can be invoked after a later one has been used.

It's been a long time since I tested this, but my experience in the past was that it is only possible to revise 'down' the list, regardless of the series.  Adding new values further up the list wasn't a problem, but these new values don't have any impact on existing objects that are already below them.  Of course newly created objects can start anywhere on the list.

 

By the way, it is possible to put the dash ("-") before either the numbers or the letters, but it can only be listed once in the file (like Mike stated.)  Any of these series would be fine:

 

-

1

2

3

A

B

C

 

(or)

 

-

A

B

C

1

2

3

 

(or)

 

1

2

3

-

A

B

C

 

(or)

 

A

B

C

-

1

2

3

    Terms & ConditionsCookie settingsAccessibility statement