Dissociate Described by Document in bulk

[EMonet]

Version: Windchill 12.0

Use Case: A user changed the revision of EPMDocument, as well as the associated WTPart, but forgot to take the WTDocument at the same time.

Description:

Hi,
A user changed the revision of the 3D models and drawings, which changed the revision of the associated parts, which is normal.
Unfortunately, they did not collect the associated documents, which also need to be revised and associated with the new part revision.
We are now with parts with the new revision associated with documents with the old revision.
And there are a lot of them.

I am therefore asking you how I can, for a large number of parts, dissociate, for example, revision A from a document and replace it with revision B (without the part taking on a new revision)?
With loadfromfile, I can associate revision B, but I end up with both revision A and revision B associated with my part. So I need to dissociate revision A, or is there another solution? Hence my question.

And to go further, what are the parameters or best practices you have to avoid this kind of error? (Using Reference Documents is not what we want)

Thanks,

[avillanueva]

Ok, so the change is really with the WTPart since that is how the documents are linked. To answer the last part, you will need to look into the site preferences to the revise collector. Here is where you can set the defaults that will include related documents by default when you revise things. Be sure this is what you want in all cases.

As far as the fixing the revisions of the missed docs. How many are there? My answer might depend on that number but they would need to be revised on the side. then I think its just a matter of editing out the WTPart, removing the old versions from teh Describing documents, and you can paste in new version say from a search results in.

[EMonet]

Hi avillanueva,

Ok, Thanks for the preferences, I'm going to take a look in the Revise collector.
For how many there are, there are about 300 parts where 2 documents need to be changed inside. If there is no other solution, we will have to be done manually.

[avillanueva]

You might be able to select the parts again if only to use the collector, collecting related documents, to revise. Once select, try excluding the Parts leaving only the documents to revise. See if that works on a small set. It still is an issue to reassociate the version together and align with the parts.

[EMonet]

Yes, I can revise the documents like that or select them directly in a search.
But my problem is that the old revision is still associated with the part.
To reassign the new version, I can do so with a loadfromfile PartDocDescribes
But I have both versions associated with the part

[d_graham]

@EMonet,

Yes, this can be easily fixed with a script. I do stuff like this all the time.

Is the logic that the WTPart and its associated WTDocument must have the same rev?

If this is the case or if you have other bombproof logic to find the problem associations, I can write you a script to fix it,

The script can fix the association to the correct WTDoc without iteration anything too, which I believe is what you want. True?

If you need help contact me at windchill.developer@yahoo.com 

David

[EMonet · Accepted solution]

@d_graham ,
That's what I ended up doing.
So, as there doesn't seem to be a standard solution, I developed a script using :
QueryResult qrLink = PersistenceHelper.manager.navigate(part,WTPartDescribeLink.DESCRIBED_BY_ROLE, wt.part.WTPartDescribeLink.class,false);
while(qrLink.hasMoreElements())
{
  WTPartDescribeLink link=(WTPartDescribeLink)qrLink.nextElement();
  WTDocument docDescribedBy=link.getDescribedBy();
  if (docDescribedBy.getNumber().equals(docNO)){
     PersistenceHelper.manager.delete(link);
  }
}