Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Multi-CAD/ORGID Integration With Windchill

Multi-CAD/ORGID Integration With Windchill


WGM Code (both ProE and other CAD WGMs) governs file name uniqueness and not the database.  Because of this one flaw, Windchill is not a truly multi-CAD tool.  It behaves like a single Pro/INTRALINK.  Cannot import customer data and compare, collaborate with other companies.  OOTB ProjectLink has conflicts with duplicates the same file name in the ProjectLink workspace with commonspace.


  • Just remove the file uniqueness code in WGMs or change it to reflect it against the database.
  • In an organization, the number is unique to identify a part.
  • Types Documents that describe the part can be numbered identical to the part number.
  • Documents of the same type have a unique number.
  • Ability to migrate multiple Pro/INTRALINK and Windchill to 1 Windchill with multiple organizations
    • no data cleansing required
  • Abiltiy to identify multiple CAD files with the same doc name
    • OOTB ProE with saving to hard disk
  • Just have the uniquenss based on database unique indexes (script):

out with the old:

SQL>  drop index WTPartMasterKey$UNIQUE;

SQL>  drop index WTDocumentMasterKey$UNIQUE;

SQL>  drop index EPMDocumentMasterKey$UNIQUE;

on with the new:


SQL>  CREATE UNIQUE INDEX WTDocumentMasterKey$UNIQUE ON WTDocumentMasterKey(wtkey,idA3organizationReference) TABLESPACE INDX STORAGE ( INITIAL 64k NEXT 64k PCTINCREASE 0 );

Or  SQL>  CREATE UNIQUE INDEX WTDocumentMaster$UNIQUE ON WTDocumentMaster(WTdocumentnumber,doctype,idA3organizationReference) TABLESPACE INDX STORAGE ( INITIAL 64k NEXT 64k PCTINCREASE 0 );

SQL>  CREATE UNIQUE INDEX EPMDocumentMaster$UNIQUE ON EPMDocumentMaster(documentnumber,doctype,authoringapplication,idA3organizationReference) TABLESPACE INDX STORAGE ( INITIAL 64k NEXT 64k PCTINCREASE 0 );

SQL>  CREATE UNIQUE INDEX EPMDocumentMasterFile$UNIQUE ON EPMDocumentMaster(cadname,authoringapplication,idA3organizationReference) TABLESPACE INDX STORAGE ( INITIAL 64k NEXT 64k PCTINCREASE 0);


  • Import any customer or different site data to another ORGID.
  • No conflicts with conflicting file names (i.e. the most common default prt001.prt)
  • No migration issues
  • No ProjectLink issues with duplicates
  • No code customization.  Lighter WGM code and overhead.
  • No conflicts with multi-CAD integrations.  (i.e large companies use Solid Works, ProE, Ideas)
  • Have identical Numbering for all the different CAD files without extension in the CAD Number.  Group all files with the same document number ID.
  • Since WGMs are already connected to Contexts, the ORGID is already established.
  • EPMDocument is purely based on reference links which is established on save/upload and checkin.  If you open an assembly and there is multiple files of the same name, just like multiple projects, it will pull the right files.
  • the only check is to place a warning if you want to place open multiple files in a ProE session.  This is the only prevention in the code of ProE and not the workspace.  Users have to sometimes have CAD files that may have the same file name/number but diferent authoring tool because of:
    • converting legacy
    • converting for other customers
    • working with other CAD



SQL Server issue:

SQL Server has issues with indexes that goes beyond 8K. SQL Server is such a immature database tool. I have a mile long of issues why customers should not go with SQL server. The license may be cheap but it is horrible to support and maintain. I just wish PTC support in the future PostgreSQL. Like RedHat Linux, some company can just support it.  I went to SQL server DBA courses and TC meetings regarding moving from Oracle to SQL Server and both sadly asked me "Why would you do that?".  I told them it was not my decision and all of them including the SQL Server DBAs from some large banks shook their heads in pity.

1 Comment
Status changed to: Archived