Issue:
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.
Requirement:
- 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);
Result:
- 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
