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 WTPartMasterKey$UNIQUE ON WTPartMasterKey(wtkey,idA3organizationReference) TABLESPACE INDX STORAGE ( INITIAL 64k NEXT 64k PCTINCREASE 0 );
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 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.