Add to workspace fails with strange override situation

[DonSenchuk]

I have a group of users that attempt to open an assembly and they get an 'Add to workspace failed".

For the failures, the event manager says a family table member would become incompatible but also give an override option that strikes me as a little strange. That override option is to override the latest version (C.0) with the oldest version (1.2).

The difference between the two is that the older version has a few instances that we broke out of the family table a couple of years ago (due to those instances not being a COTS number). I've done this dozens of times to dozens of different family tables and have never seen this cause a problem.

I've verified that the Add to Workspace Required Dependents settings are identical (Latest, Working) I've followed that up with changing this on both accounts, same error (Latest, Production Released)

I've started taking more drastic measures, such as removing what I thought were the offending components from the assembly, but it gives the same error for that pin (ms16562) even though it's not in the model tree anywhere.

The problem account can search, find and open the latest generic of that pin. He can search-find-open the components that were once in the family table but are now broken out. He just can't open an assembly that's using them even when I can.

Hopefully some suggestions steer me onto the right path. Dealing with Tech Support on ITAR matters is always a last resort.

[TomU]

Just for fun, could you temporarily rename his cache folder and try again with a new cache and a new workspace?  The fact that he can't open it but you can seems to indicate a permissions issue (unlikely in this case) or a workspace or cache related issue (more likely).

[DonSenchuk]

I tried two workspaces but I didn't delete his cache. Will get on that as soon as he's back from lunch.

[DonSenchuk]

I removed his cache folder.

No luck.

I moved all the roll pins in question to a location he demonstrably has read and download permission to

No luck.

I checked out the family table of MS16562, re-verified it, checked back in.

I checked out 4 individual roll pins that were once in the family table, regen, check back in.

I checked out the sub-assemblies that use those 4 roll pins, regen, verify the one, check back in.

I checked out the main assembly, regen, check back in.

No luck.

I change config files from his dept. to mine.

No luck.

I logged in as him on my workstation instead of on his workstation.

No luck.

[TomU]

You said you could open it from your account.  Maybe it's time to re-verify that.  Double check that you can indeed open up everything correctly.  If you can, then maybe temporarily add him to the same groups you're in (or even the administrators group).  Maybe this is a permissions issue.  (Are you using security labels???)

[DonSenchuk]

The strange thing is that if he opens each pin individually plus the MS family table, no errors. But then, with those pins in memory, attempt to open the top assembly and it wants to roll back through 3 revisions (C > B > A) to the first revision (1.2).

That makes me suspicious that it's actually a permissions issue. He obviously has permission to download and open all the files' latest versions.

I'm willing to try anything at this point, so that will have to be one of the tests.

[Gagan]

Hello Don

Couple of Months back even i came across the similar issue in Windchill 9.1 , i could able to resolve using advance add option .

1. If family table part is existing in the workspcae , remove it

2.search for the generic part in the common space ,click on add to work-space

3.Go to advance tab select all the insistence's and the generic and add to workspce ,

Regards

[BenLoosli]

Maybe have IT blow away his account and create a new one. There may be an OS issue.

[DonSenchuk]

Thanks for all the help everyone.

It was a conflict with a part that was in the family table of MS16562 but was called something totally different than 'Roll Pin'. When I went through the structure tab of the assembly I just looked for Roll Pin assuming that they would all be named the same thing. While the assembly is not huge, it's also wasn't small enough for me to go piece by piece making sure each individual component wasn't from the old revision of that family table.

[rcrerar]

Hi Don,

In my opinion you have been very lucky that you have not encountered this error before. Windchill has never liked removal of instances from family tables (this is a very common issue). Don't do it ever.

What has happened is the current release of the generic is in the workspace but the user has then asked for an instance that it no longer contains. Creo calls in the instance from the old file because it knew it was in an older version. The exact mechanics behind this i'm a little rusty on.

The fact you have been able to do this dozens of times before is probably because the files have not been reused since and you are getting away with it.

How do you resolve this? I'd be tempted to add the instance back into the family table temporarily to get the assembly to open. I would then suggest saving it out as a separate new file with new name and replacing that in the model. Remove the temp instance from the FT using undo checkout.

Hope that this makes sense to you.

[DonSenchuk · Accepted solution]

Hi Roy.

Turn out that the dozens of time I've done it before was because I did it correctly. This means saving the instance as it's own stand-alone part and checking it back in to Commonspace.

This time, it was someone else that just removed that instance and did NOT make it a standalone part. There were some lifecycle differences at different versions which meant Prod. Eng. was able to open the files just fine but downstream users were unable to open it at all.

While I could have just set the deleted instance to a released state, that would mean the downstream users would be unable to use the latest version.

My solution was to open the old version in a workspace, back it up to a local folder, break out the instance, rename the old instance in Windchill, upload the broken out instance from my local drive, check it in, rev it and manually set it to released. This creates a situation where that pin is not part of the family table any more but it was the quickest way to resolve it without holding up production any more than the issue already had done.