Latest version is not the latest?

[DaveEngel]

Has anyone seen a situation where PDMLink (9.1 M060) thinks an earlier version of a file is the latest version?

I have some family tables where the generic and several instances always mark as out of date when we add them to workspaces. I did some investigation and found the latest version of the generic is G.5, however the system thinks F.0 is the latest.

If you look at the information page on G.5, the “Go To Latest” link is there and goes to F.0?!

-Dave

[sdrzewiczewski]

Are you providing any other criteria such as State?

> Has anyone seen a situation where PDMLink (9.1 M060) thinks
> an earlier version of a file is the latest version?
> I have some family tables where the generic and several instances
> always mark as out of date when we add them to workspaces. I did some
> investigation and found the latest version of the generic is G.5,
> however the system thinks F.0 is the latest.
> If you look at the information page on G.5, the "Go To Latest" link
> is there and goes to F.0?!
> -Dave
>
>

[mkraegeloh]

yes.

stupid implementation. my guess is the first G version ever was (manually?) created before the first F - so the
SeriesSortValue for G is now less than the one for F.
needs fixing the values, easiest thru sqlplus or the like. tech support might have a tool to fix it, not sure.

hth, martin

[bellj]

This is what PTC TS gave me to do when my versions aren’t sorting right.


1. Take a Backup of the Table, ‘SeriesSortValue’

CREATE TABLE Backup_SeriesSortValue AS (SELECT * FROM SERIESSORTVALUE);



2. Delete all rows from the SeriesSortValue table.

Delete from seriessortvalue;



3. From a Windchill shell run:
java wt.series.SeriesSortValuePopulater

joe bell
CM Application Administrator
Information Management & Technology Solutions
GPS Sustainment Information Management System
719-380-5932
bellj@gpssims.com<">mailto:bellj@gpssims.com>

[MikeLockwood]

Just FYI for all – we did this following upgrade to 9.0 and it worked…

It’s interesting to look at the actual database tables before and after.

[patrick.chin1]

I've seen that issue where they don't lock/release pervious versions of an generic with it's instances. Someone can checkout a previous version of a generic because it is still in their workspace and create an new instance. At the same time a later version is in windchill.

The sql and reset the table is only a temporary fix. It doesn't prevent the issue from happening again.

On a side notein a higher level,configuration control with Change Notice release. Most workorders/TK's which is what the manufacturing side uses refers to a manufacturing change notice that released it and the released enginering documents/drawings refer to an engineering change notice. Each engineering change notice points to a specific effectivity of manufacturing workorders/TK's which is on which floor/time/location facility. With that said, who is your user reading the information and what is their functional role requirements.

Engineering works and modifies latest, but the history of released configurationshave to be captured which the other cascading functional groups use downstream. This is why we use Windchill and not ProI.

Hope that helps,

Patrick