Notice and Task Numbers Out of Sink

[BrianToussaint]

We are on 11.2 and we keep having this issue where our Change Notice and Change Task numbers get out of sync.  We can not duplicate it or figure why it happens since there is nothing in the logs.  All of a sudden the numbers will go out of sync and a Change Notice number goes missing but the Change Task numbers stay sequential.  Does anyone know why this might be happening?  We do have multiple Notice and Task soft types.  We had it happen before in 11.0, but usually that was because someone created an extra task in a Notice just to see what it would do.  This has happened at least 3 times this year in 11.2.  Does anyone know why this might be happening?

[adesai_87]

Hi Brian,

Refer to the Article: https://www.ptc.com/en/support/article/CS260830, which might give some pointer for further analysis.

Regards,

Amar

[BrianToussaint]

Hello Amar,

That does not explain what is happening here.  What will happen is that all of a sudden a Notice number is missing for no reason.  We will go from CN 10222 to CN 10224.  There is no record of CN 10223.  There are no errors in the log.  This then throws the numbers off and confuses people.

Brian

[BenLoosli]

Do you have the database set to not skip generated numbers?

By default, when their is a restart of Windchill or a time lapse between a number being pulled, the sequence jumps to a higher number and causes skipped numbers.

[BrianToussaint]

@BenLoosli  I would think not, but what where would I find that?  We restart the Windchill nightly and only have skips in numbers when this happens and we have been running CNs for almost 9 years now.  The only thing close in the time frame was there was a user that had the first tab of a CN opened for 20 minutes or so and then canceled it.  However, we have tried to duplicate this on our test server and can't get it to do it.

Thank you,

Brian

[BenLoosli]

Here are some articles on numbering in Windchill.

https://www.ptc.com/en/support/article/CS113612

https://www.ptc.com/en/support/article/CS21621

https://www.ptc.com/en/support/article/CS18948

[d_graham]

Brian,

If you are using OOTB OIR for number generation and your standard is one task per CN there are three things I'd check.

1. Business Rule  Change Association Rules - PTC000007 cardinality.  Is it 1:1? (only one Task per CN)

2. db sequence WTCHANGEACTIVITYID_SEQ

3. db sequence WTCHANGEORDERID_SEQ

The sequences' CACHE_SIZE (which I'd set to NOCACHE), LAST_NUMBER and INCREMENT_BY should be identical. If they are but CACHE_SIZE is still the default (20). Set CACHE_SIZE to NOCACHE for both sequences.

If those all look good I have another way to ensure they are always in synch.

My other way keys off the most recently created CN.  If a new CN is created its number and it's Task's number are generated as the most recently created CN's number + 1.

This guarantees the numbers are in synch.  The only limitation is that Change Association Rules - PTC000007 cardinality is set to 1:1 (only one Task per CN).

Check out the Business Rule and the sequences first and then get back to me.

David

[BrianToussaint]

Hello David,

I am using a modified OOTB OIR to point to my teams and lifecycle. The number generator portion is the same.

1. It was not set to 1:1.  I set this on my test system and it still would through them out of sync if I tried to create more than one task per CN.  This was after I reseeded both of the sequence tables to 10,000. The CN came out as 10,002 and the CN task came out as 10,003.

2.  On my SQL database it now shows last entry in WTCHANGEACTIVITYID_SEQ as 9410  Dummy - X  Value 9898

3. On my SQL database it now shows last entry in WTCHANGEORDERID_SEQ as 9406   Dummy - X   Value 10002.

I cannot find the sequences CACHE_SIZE, LAST_NUMBER and INCREMENT_BY in my database.

Thank you,

Brian

[d_graham]

Brain.

Are you using SQL Developer and some other app to look at the dB.

Here's a snap shot of the sequence from an 11.1 dB (11.2 and 12.0 look the same).

Note CACHE_SIZE = 20.

That said, if you have the rule set to 1:1 and they still get thrown out of synch if you create more that one task I'd say PTC needs to work on that.

In the meantime, I'd suggest not using sequence to generate the number.

I do like getting the number of the most recent CN and add 1 to it.

I set the OIRs for both the CN and the Task to key off the most recent CN number.  In short, because the code used to generate the number for both is identical the numbers for both have no choice other than to be identical.

I have not tested my code trying to create more than one task but I'd think you'd get a Uniqueness Exception regardless of the how the rule cardinality was set. And the CN number and the Task number would always be identical.

If you need help with this let me know.

David

[BrianToussaint]

David,

Sorry about not getting back to you sooner.  I needed to finish up my items for Creo 7 rollout over the weekend.  I am getting back to this now as we had it happen again last week.

I am using SQL Server and accessing it through SQL Server Management Studio.  I have to columns in the table. One is dummy and the other is value.  I'm attaching a screen shot of the properties for dummy and value.

Brian