Is it possible to change the TYPE of object from Reference document to drawing document in PDM Link?

[TG_9141045]

I have an WT part which is already existing PDM Link and associated with reference document, Now I need this reference document to be converted or changed to be drawing/document type. Is it possible??? If yes please guide me..!  @bsindelar  @STEVEG @BenLoosli @MikeLockwood @AL_ANDERSON @tstacy 

[STEVEG]

You cannot change the type of an existing object.  Unless something changed in the newest version.

I came across documents in the past that were not the correct type.  We ended up exporting the documents, deleting them in PDMLink then creating them again as the correct type.

[d_graham]

You can change a WTDoc to a different type of WTDoc. The only caveat is you will orphan any attribute values where the attribute is not in the target WTDoc.

If you toggle the WTDoc back to the original type the orphaned attribute values will reappear on the WTDoc.

So, anytime you change type you should also remove the orphaned attribute values from the database. It’ll do no harm to leave them but do you really want orphaned entries in the database.

You cannot change a WTDoc to an EPMDocument. You must stay within the object’s class. Any type under the class is fair game.

I actually wrote a utility that runs in a Windchill shell to do this. To run it you enter a class, number and if attributes that are not in the target type should be deleted or not.

The utility confirms there is an object of the class and number and then displays all the subtypes of the class. You select the type you want and all iterations get changed.

The utility worked great and came in handy when you needed it. If could also run by reading a file in the event we needed to edit a lot of objects.

David

[STEVEG]

Excellent information.  Thank you.

[TG_9141045]

Hello David,

Would you let me know what is the utility which you have run?

And would like to know if this doesn't required any coding to convert a Type of reference document to drawing document.

Thanks,

GTC

[d_graham]

GTC,

The utility is a Java class that I wrote myself. It does not require any coding to run it.

It does not require iteration anything it simply makes the change.

It’s more like changing an objects revision. You don’t iterate you simply change it.

It’s quite easy to toggle back-and-forth too.

Here's an example:

I start with a WTDoc that has no subtype and I want to change it to subtype VaultDrawing.

Note: version is F.1

In Windchill shell I run the utility.

I refresh the Document's page.  All iterations have been re-typed to VaultDrawing

Latest is still F.1 but re-typed to VaultDrawing

At random I selected a much earlier version just to demonstrate that all iterations where re-typed.

Version A.3 below.

David

[rhart]

In my notes I have an article about a similar utiliy https://www.ptc.com/en/support/article/CS7287

[TomU]

Looks like it's no longer available:

[rhart]

view the Japanese version and google translate back 😂

[TG_9141045]

Hello David and all,

I am attaching some pictures for your reference...i have a part and sub part associated with it, which is reference document....and i would like to change its TYPE to drawing document

In the above picture you can see that i have one WT part and another reference document associated with it.

Here i would like to change its TYOE from Reference document to Drawing document.......

Just let me know what is the exact solution for it..... I feel you are capable of answering this...

Thanks!

[d_graham]

What is a "drawing document"?  Is this a custom WTDocument type you have in your system?

I've never heard of it.

Or are you referring to a CAD Document?

If you are referring to a CAD Document what you want to do is not possible.

WTDocument and EPMDocument (CAD Document is a subtype of EPMDocument).

As mentioned in my earlier post, you cannot change a WTDoc to an EPMDocument. You must stay within the object’s class. Any type under the class is fair game.

I edited my utility to include ALL types from the object's class.

You can see Reference Document is available for selection now.

[avillanueva]

Echoing @d_graham , I use exactly the same method. I wrote a RMI Server command since (perhaps I am dating myself) it involved running commands that could not be executed in a client:

package customization.typeChange;

import wt.method.*;
import wt.type.*;
import wt.fc.*;
import wt.util.*;
import java.rmi.RemoteException;

/**
 * @author antonio.villanueva
 */
public class TypeChangeServerCommands implements RemoteAccess {

    /** Creates a new instance of TypeChangeServerCommands */
    public TypeChangeServerCommands() {
    }

    public static Boolean changeType(Typed object, String type) 
    {
        try 
        {
            object.setTypeDefinitionReference(TypedUtilityServiceHelper.service.getTypeDefinitionReference(type));
            PersistenceServerHelper.manager.update(object);
            return Boolean.TRUE;
        } 
        catch (RemoteException e) 
        {
            e.printStackTrace();
            return Boolean.FALSE;
        } 
        catch (WTPropertyVetoException e) 
        {
            e.printStackTrace();
            return Boolean.FALSE;
        } 
        catch (WTException e) 
        {
            e.printStackTrace();
            return Boolean.FALSE;
        }
    }
}

This would then be called from my client scripts which I wrote interactive ones like @d_graham or mass update versions. Reason this is a touchy area is that this is not supported by PTC. I treaded into soft-types in my install but I have been trying to limit their use or reverse things ever since. They are not bad but users are users and they often pick the wrong type all the time.

So, in a client, the call looks like this:

                    Typed typed = (Typed) versionedObjects.get(i);
                    try {
                    wt.method.RemoteMethodServer rms = RemoteMethodServer.getInstance(new URL("<PDMLink URL>"));

                    Class[] args = {Typed.class, String.class};
                    Object[] args2 = {typed, typeNames.get(newType)};
                    Boolean r= (Boolean)rms.invoke("changeType", "customization.typeChange.TypeChangeServerCommands", null, args, args2);
                    if (!r.booleanValue())
                        result=false;
                    }
                    catch (Exception e) {}

So, having your typed object iteration and the string name of the type, it will pass that to the class above and execute the change.  I would love to make this an admin UI action but since I do this so rarely, it has never bubbled to top of my list. Add "Alter Revision Letter" to my to do list as well.

[d_graham]

I recently had a request for the type change utility.

I rewrote it to make it universal and to provide an option to delete all orphaned attributes.

The utility is run from a Windchill shell and starts by asking the class of the object to be changed, WTPart or WTDocument.

Next the tool asks if the user wants to commit any changes to the database. (Maybe this is just a test run).

Next the tool list all types from that class and asked the user to pick one.

Next the tool then lists all Global attributes from

all types that are referenced by the type selected.

Next The user is then asked if they want to delete all attribute not list above as any not listed above will be orphaned.

Next the user enters a single number or a text file with one number per line for a bulk type change.

Additionally any numbers that have an iteration that is NOT checked in are listed and the user is warned that these will be skipped. (We are not changing anything that’s currently checkout by someone.)

Next the tool displays in the shell the number of numbers and the total number of iterations that will be retyped.

Next the tool displays all of the users inputs and asks if they should proceed. (This is done as a final check and gives the user one last chance to bail).

Finally, the tool runs doing its thing and print a log with the user’s inputs and any errors including listing the non-checked in iterations that were skipped.

Works great and testing shows it’s bombproof. 😁

Best of all, it can very easily be expanded beyond re-typing just WTParts and WTDocuments.

[AL_ANDERSON]

I recommend that you make a new wtdocument of the appropriate type, check out the part to add your new described by wtdocument object and remove your old references document type wtdocument object, then check in the part (assuming there is only one latest version to update and you don't have other view versions to similarly update). You cannot generally delete a document while it is linked to a part iteration, even an old one. 

Alternatively, delete latest iterations of revisions that reference the original document, then delete the old document, and make a new wtdocument of the right document type to then check out the part, add the described by link, and check it in.

I suppose a final way would be to delete all iterations of the part and the bad document, then just a new part with a new wtdocument of the right type and link to the new part. But  that is difficult if the part has been used by any other parts in a product structure since you won't be able to delete all iterations of a part still used by other part iterations, even if they are not the latest iterations.

There is no administrative way to re-type an object. We have some custom programs we have made over the years for mass conversions of one kind or another to change something we decided that we didn't like any more, but they were always specialty jobs. We have never made any customization that can ad hoc change any wtdocument of one type into a wtdocument of another type.

Now, if I really really had to do it and I couldn't just make a new document for some reason, then I would go to my DBA or local programmer in Windchill who knows SQL, and talk that programmer through the steps of finding the tables in the columns in WTDocument that link to its document type, change that to the new type, then find all the links to light type attributes and attribute values for the document to remove them and replace them with attribute links and values for the new type, then finally find all iterations of all wtparts everywhere to change any references links they have to the WTDocument Master to remove them, then replace them with new Describe by links from latest part iteration per version to latest document iteration per version. That may or may not be all the necessary changes, but I'd start there and see how it went. All of that would be difficult for an experience programmer and fraught will all kinds of peril for an inexperienced developer who will inevitably miss, forget, or mess up something and be unable to fix it without PTC support because none of that would be supported. So, be sure to back up any tables you work on before you try anything, and be sure to do the testing on a couple of non-production environments before any production environments.  Depending on your system and the complexity of the document type data, that kind of change will usually run into some odd PTC-internal column or link table that you break and then have to figure it out as you go with testing, trial, and error.

[rhart]

--find out the type id for a part
SELECT A0B.WTPartNumber,A0.branchIdA2typeDefinitionRefe FROM WTPart A0 INNER JOIN WTPartMaster A0B ON (A0.idA3masterReference = A0B.idA2A2) WHERE ((UPPER(A0B.WTPartNumber) = '<MY_PART_NUMBER_EXAMPLE_OF_TYPE'>'))

--set a new type for a part
UPDATE WTPart
SET WTPart.branchIdA2typeDefinitionRefe = '407551298'
FROM WTPart A0 INNER JOIN WTPartMaster A0B ON (A0.idA3masterReference = A0B.idA2A2) WHERE ((UPPER(A0B.WTPartNumber) = '<MY_PART_NUMBER_TO_RE-TYPE')) 

I'm not recommending anyone should try changing the type! It's interesting to see how Windchill types work.

Recently we discovered that all of our custom part soft-types had been changed to the OOTB part type, we had to do this to 000's of parts to get them back to the right type.