Skip to main content
1-Visitor
October 27, 2014
Solved

"CAD part is not unique"

  • October 27, 2014
  • 6 replies
  • 42422 views

Hi

We have more than 20,000 library parts, out of that 15,000 part successfully moved into windchill library folder .

The remaining 5000 parts when I am moving to windchill from local drive, it is showing "CAD Part is not unique".

Because of this issue , we were not able to upload the assembly .

Windchill implementation team working on this issue last one month but still not able to find the root cause.

Note:Those 5000 parts are not present anywhere inside windchill.

Best answer by cgorni

To close this community thread on CAD part is not unique

 

Summary of the exchanges and list of solutions for this error also documented in articles CS198426 or CS75938:

  • Windchill enforces uniqueness on CAD Document Number and filename
    • Number uniqueness may be configured at Site or Organization level during installation or upgrade, see articles CS55835 and CS360080
  • Therefore the error indicates an object with the same identifiers must exist in the system.
    • You may want to remove the duplicate objects from workspace and rename it in the CAD application before import or save to workspace
    • Or you may add the server’s object to workspace to override or reuse the locale version, see resolution of article CS38369
  • The existing objects may not be findable for different reasons:
    • You do not have permissions to access the Organization or Context and view the object
    • The CAD object has been uploaded in another user’s workspace
      • Windchill Administrator can find some scripts here to identify which workspace
      • You need to run them on the Oracle database machine.
      • Example:
        • C:\>sqplus {wc_schema_username}/{wc_schema_user_pw}@{Windchill_SID} @{Path_to_SQLScript}
        • C:\>sqlplus guest/guest@wind @c:\temp\wc7_find_download_caddocs_cadfilename.sql
      • When prompted you would need to specify the filename of the CAD Doc.
    • The Windchill database could be corrupted following a migration or upgrade, same for the workspace’s locale cache itself.
      • These last options are rare and may also require a Windchill Administrator to investigate further with PTC Technical Support assistance.
      • You could delete and recreate the local Creo cache as suggested by article CS45093
    • Family Table instances could bring additional challenges, refer to article CS290073 to manage possible conflicts
  • Another reason of the error could be that you gave the same name to different object types (part, assembly, drawing, etc) and drop the file extension during upload:
    • In this case you could set the preference Operation > Upload Operation > Upload > Upload Drop Number File Extension to No from Windchill Utilities > Preference Management
  • Interesting explanations and tips can also be found in articles CS24096 or CS179676

6 replies

1-Visitor
October 27, 2014

Hi,

Are you sure it is not just an issue of part's name or file's number ? I've already got this message when file's name or part's number is existing in the library (associate with another part).

1-Visitor
October 27, 2014

No,It is not exist in the library.


1-Visitor
October 27, 2014

How did you moved your data? By import manager?

1-Visitor
September 13, 2016

Hello Haris,

Just today I received same error what you were getting and got solution too.

Basically it is a question of upload. I tried to checked in from my local work space & uploaded but checked in error shows that xx.prt is not unique due to another person uploaded same part number in his respective work space & still same part in his local work space.

I request that person to clean up uploaded work space and tried same part to checked in and it is successful.

Hope this will help you and mark correct answer if you agree the same.

Thanks,

Jitu Thakor

12-Amethyst
June 14, 2017

Got the same error again and again, despite there isn't any other cad file or document called the same way.

The more I go along using this software, the more I worsen its reputation. It is just making you lose time in such stupid problems (and so many other happened! like "workspace corruption" for example...shameful).

And their development team? they say they don't know what's caused by....like what they say about people not recognizing their own calligraphy!!

1-Visitor
June 14, 2017

One way to force this error to occur is to have a drawing and a part and give them both the same 'number' by removing the .prt and .drw suffix. This will be flagged as 'not unique' when the user tries to check them in.

12-Amethyst
June 16, 2017

Hi David Schenken ‌and Manjunath RV‌,

thanks for your replies.

In the meantime on Wednesday I found what the problem was and the workaround.

I already knew the error coming both in the case of "same number for prt and drw", and in the case of the upper case text.

But these were not my cases (unfortunately, cause I would have fix the problem sooner).

I discovered instead this issue:

-I retrieved, from the local disk, a step assembly which, together with all of his components, was already named on the disk. (the filenames);

- For reasons that I don't include here for easiness of description, upon retrieval one of his subassemblies took the default name that Creo gives to brand new unnamed stuff (it was asm0001);

- The problem was that there already was a asm0001 in another workspace, so when I firstly tried to save and upload the asm, it gave me the "CAD part is not unique" error;

- "no problem" I told myself, I just have to rename the asm0001 to, let's say, b.asm, and the problem is solved, as often done before.

- but no, the software told me again the same error as if even the new name b.asm was around somewhere (I renamed both file name and number)..

- with absolutely no idea of what the cause was, I solved the thing by simply erasing the asm from the WS, then I re-uploaded the asm and did, as first thing (before uploading), a local rename of the assembly so that there wasn't any asm0001 around. Then, I uploaded it and without any problem.

So, during the first retrieval it seemed like the software remembered that the previous name of b.asm was asm0001 (which had a conflict) and so "extended" somehow this conflict to b.asm (even if there wasn't any b.asm around!).

I think it might have been a problem lying "undergound", at level of the core machine-code (don't know how to call it) of CAD parts. (as if this core-machine-code associated to the cad part hadn't been renamed together with the "surface-level" name b.asm).

I hope to have been clear enough and maybe to have helped also the original poster Haris Surya, if this was his case too.

Bye

1-Visitor
October 9, 2019

I had kind of a strange problem, while checking in the brand new files I've got the error "the part is not unique". To my shame I made a mistake. Inside my workspace I renamed the drawing to 001.prt and a part to 001.prt (same extensions) within a parameter "Number". While the file names were 001.drw and 001.prt the Numbers were the same. Windchill doesn't allow to have same Numbers as same as same file names.

 

Beside it, when you simultaneously  checking two files with the same parameter "NUMBER" the windchill compares them to themselves and gives you the same error - not unique! You looking for this name in a commonspace while missing that they are not unique to each other.

 

Even I find it strange that the same number is permitted in workspace while it is not permitted in a commonspace!

23-Emerald III
October 9, 2019

Same number is allowed in the workspace because you have not checked the files into Windchill and thus you could rename them before doing a check-in or upload and never have an error that Windchill detects. Think of your local workspace like a folder on your workstation. Only you can see what is in there, so the software leaves it alone. Do an upload or check-in and Windchill now has to check all files to be sure that what you are doing is unique.

 

Setting 'remove file extension from number' compounds the issue. Unless your drawing numbers are totally different from your assembly/part numbers, this setting will cause a conflict every time. One of our CAD rules is that part and assembly numbers MUST be unigue. We do not allow 123456.prt and 123456.asm to exist. We do allow a 123456.drw, which is why the remove file extension from number causes the error for us.

cgorni16-PearlAnswer
16-Pearl
May 10, 2022

To close this community thread on CAD part is not unique

 

Summary of the exchanges and list of solutions for this error also documented in articles CS198426 or CS75938:

  • Windchill enforces uniqueness on CAD Document Number and filename
    • Number uniqueness may be configured at Site or Organization level during installation or upgrade, see articles CS55835 and CS360080
  • Therefore the error indicates an object with the same identifiers must exist in the system.
    • You may want to remove the duplicate objects from workspace and rename it in the CAD application before import or save to workspace
    • Or you may add the server’s object to workspace to override or reuse the locale version, see resolution of article CS38369
  • The existing objects may not be findable for different reasons:
    • You do not have permissions to access the Organization or Context and view the object
    • The CAD object has been uploaded in another user’s workspace
      • Windchill Administrator can find some scripts here to identify which workspace
      • You need to run them on the Oracle database machine.
      • Example:
        • C:\>sqplus {wc_schema_username}/{wc_schema_user_pw}@{Windchill_SID} @{Path_to_SQLScript}
        • C:\>sqlplus guest/guest@wind @c:\temp\wc7_find_download_caddocs_cadfilename.sql
      • When prompted you would need to specify the filename of the CAD Doc.
    • The Windchill database could be corrupted following a migration or upgrade, same for the workspace’s locale cache itself.
      • These last options are rare and may also require a Windchill Administrator to investigate further with PTC Technical Support assistance.
      • You could delete and recreate the local Creo cache as suggested by article CS45093
    • Family Table instances could bring additional challenges, refer to article CS290073 to manage possible conflicts
  • Another reason of the error could be that you gave the same name to different object types (part, assembly, drawing, etc) and drop the file extension during upload:
    • In this case you could set the preference Operation > Upload Operation > Upload > Upload Drop Number File Extension to No from Windchill Utilities > Preference Management
  • Interesting explanations and tips can also be found in articles CS24096 or CS179676