It's David not Dale.
Anyway. You are correct. I did a post a while back about muli-primary contents.
PTC was of no help in resolving this. I wrote my own code to find ContentHolders of class wt.doc.WTDocument where there were more than one primary and then delete all primaries except the latest one. If latest could not be determined by Timestamp, there were close to 2000 with identical Timestamps (both create and modify), I then used the primative long id number. The larger id number is the latest.
We had ~93,000 of these. Now we have none.
As for the Filename not being right I wrote code to find objects where the UPLOADEDFROMPATH filename does not match the FILENAME. If it does not match then reset the FILENAME to match the UPLOADEDFROMPATH filename. Seems to work well. I did not bother with PTC as it is easier to simply fix it myself.
This particular dB is somewhat unique as it originated from 6.2.6 and therefore was created when Windchill*PDMLink was still quite immature.This dB's upgrade path is 6.2.6 --> 8.0(M020) --> 10.1(M010).
In Reply to Sudeep Bhattarai:
It seems like those objects have multiple primary contents. This happens
when multiple ApplicationData are created for the same object.
You will have to delete old primary contents by writing a tool. PTC tech
support might be able to help you on this as there are many clients who
have reported and fixed this issue before.
Phone: (847) 220-7008
On Tue, Feb 19, 2013 at 9:29 AM, David Graham
> Another strange one. Anyone seen this before.
> We have quite a few Primary Contents where the filename does NOT match the
> name of the file that was uploaded. It seems Windchill appended a "-1" in
> front of the files extension. This can be fixed but has anyone else seen
> this before.
> Windchill 6.2.6 --> 8.0 --> 10.1
> David Graham *Windchill Administrator*
> *Pro|ENGINEER Administrator*
> *CAx Administrator*