Experience with duplicity in EPMDocument table
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Experience with duplicity in EPMDocument table
Version: Windchill 12.0
Use Case: The database table EPMDocument contains duplicity rows for revision-iteration object.
Description:
The database table EPMDocument contains duplicity rows for revision-iteration object.
For example object ABC has two records in the database for version B.1
First is latest second is not. Object is checked-in
I do not know the root case why there are duplicated records so I would like to know, if someone has similar experience.
System history shows the records correctly but method .istheLatestIteration can not work properly.
Query Report contains the duplicity
additional information this EPM Documents are created in Catia and saved by workgroup manager in Windchill
Thanks in advanced for any experience.
PetrH
Solved! Go to Solution.
- Labels:
-
Other
- Tags:
- database consistency
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
wrk-p is a private working copy. Different than a working copy. I’m sure you know this.
As for duplicity, I had a very strange situation years ago, Windchill 8.0. CAD Docs had duplicate primary application data. And there were a lot of them. No idea how this happened. The data had originally been migrated from Pro/I to v6.2.6 using the old Pro/INTRALINK Gateway. Then it had been upgraded to Windchill 8.0 a couple of years later.
To get ride of the duplicate ApplicationDatas I wrote a Java class that would delete the oldest one keeping only the newest one.
There were never more than two, no triplets.
Windchill worked fine before the cleanup but who needs duplicate primary content in their CAD data.
Not really the same thing as your seeing but I thought you might be interested in another duplicate story.😁
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Nothing I hate more than Windchill being duplicitous. Is this just one are are there more all over the place? What does the iteration history table look like from the UI for this object? Could it be that this is a working copy (checked out object)? Or possibly an uploaded modification in someone's workspace but not checked out? Are the branches the same ID?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Hi @avillanueva
Funny thing is that the history tab looks like absolutely perfect. without any issue.
The right row is shown in the history. But if I collect the objects by API I have problem to identify which one is correct one 😄 especially if the newer iteration exists 😄
I found many duplicity records for many iterations and OOTB functions works ok because they use some mechanism that can filter the right iteration.
I am just curious if someone have seen this behavior.
I know that if user check-out the object then there are two rows for one iteration workingcopy/checkout copy but in this situation no objects are checkouted.
PetrH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I noticed that the idA2A2 of B.1 where latest is true is a larger number than where latest is false. That’s the good news.
What does the checkout info look like where idA2A2 = 165414290?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Hi @d_graham
the check out info is very interesting. All duplicated records has the getCheckoutInfo value "wrk-p" even though the object is checked-in.
Your hint is very useful. Thanks that I know how to filter this records.
In other hand I would really like to know if someone knows what case described issue.
PetrH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
wrk-p is a private working copy. Different than a working copy. I’m sure you know this.
As for duplicity, I had a very strange situation years ago, Windchill 8.0. CAD Docs had duplicate primary application data. And there were a lot of them. No idea how this happened. The data had originally been migrated from Pro/I to v6.2.6 using the old Pro/INTRALINK Gateway. Then it had been upgraded to Windchill 8.0 a couple of years later.
To get ride of the duplicate ApplicationDatas I wrote a Java class that would delete the oldest one keeping only the newest one.
There were never more than two, no triplets.
Windchill worked fine before the cleanup but who needs duplicate primary content in their CAD data.
Not really the same thing as your seeing but I thought you might be interested in another duplicate story.😁
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
In answer to your question, I believe private working copy (wrk-p) is the result of user modifying the CAD Doc and than uploading it.
In short, the checkoutInfo column gets changed from wrk to wrk-p when the content is uploaded.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Hi @d_graham
Thank you. The root case is that the cad modification is uploaded even though the object is not checked-out.
The users do not care about the modification anymore and they just keep it in the workspace for some unknown reason.
So this is the root case. Uploaded modification without checkout.
Thank you so much for your help.
PetrH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Happy to help you😁
I think we all know the reason the users leave uploaded content they no longer want in their workspace 🤦♂️
And it’s not a good reason 😂
But, hey, what can you do. It is what it is. 🤷♂️
You can lead a horse to water but you can’t make him drink.
