AnsweredAssumed Answered

How to track down in-context relations in the top level

Question asked by Joe Dunfee on Feb 18, 2009
Latest reply on Feb 18, 2009 by Joe Dunfee

Like • Show 0 Likes0
Comment • 4

As I continue to try to clean up a top level assembly, I find that there are several in-context relations that prevent several of us from working on the project together. I.e. one guy has the top level open, but another guy, who wants to work on a sub-assembly cannot because the 1st guy has inadvertently locked all those files of the sub assembly by simply opening the top level assembly.

I know how to see if an individual part has any in-context relations by the -> at the end. But, rather than hunt down and edit each individual part to delete the relations, I would prefer to just edit the ones that are created at the top level.

But, I can't figure out a way to find just those in-context relations at the top level.

Any suggestions?

Joe Dunfee

Joe Dunfee Feb 18, 2009 4:14 PM

Correct Answer

Ok, the "do not prompt" option was the final thing we needed. Problem solved.

Thank you very much.

Joe Dunfee

See the reply in context

No one else had this question

Outcomes

Dale Dunn Feb 18, 2009 1:16 PM

Joe,

Right-click on the top of the assembly's feature manager tree and "show update holders". These sit at the bottom of the tree and show where every external reference is in the assembly rebuild history. These were much hated before about 2004, because there was no way to hide them, and few uses were known for them. This is one of those uses.

Instead of deleting or reworking your design intent, how about forcing the top level assembly to open the referenced documents as read-only, so that others can edit them? This is controlled by just one of the settings in the "multi-user environment". Read about it in the help. It sounds like something you can use.

Actions

Joe Dunfee Feb 18, 2009 2:23 PM

Thank you Dale. The "Show update holders" is exactly what we needed to track down the problem links.

But, even better that system option, "Open referenced documents with read-only access" should allow us to work on sub.

But we just tested both options above. I.e. we use "show update holders" and successfully remove all of them by editing those parts. We also set the, "Open referenced documents with read-only access". But, these things didn't help us at all. Opening the top assembly, and then dragging one of the sub-assemblies and then saving will cause SW to prompt to save a bunch of other sub-assemblies that have no in-context relation to anything in the top assembly.

For reference, just opening the assembly as "read only" seems to still allow the top assembly to take control of the sub-assemblies so that others can't work on them. So, a simple open as "read only" doesn't help.

Perhaps we either need to give up on the collaboration, or continue to educate ourselves. This is a complex issue, and having less than 100% understanding of it is not really useful.

Joe Dunfee

Actions

Dale Dunn Feb 18, 2009 3:11 PM

There's another setting somewhere "do not prompt to save read-only documents" that is an essential partner to opening referenced documents as read-only. Once you've got these going, you need to get used to using the reload tool to open referenced documents that you need to edit as read/write. This is the price of collaboration.

If you find "collaboration" and "multi-user environment" in the help, it can tell you about those tools, but in 07's help I missed anything about a strategy for implementing it. There may be a guide on the customer portal somewhere. I'm referring you there because we're near the edge of what I know about this. I explored it back when it was new ("collaborating" between two sessions of SW on the same computer), but I've never had an actual need to use it. I hope I've given you enough clues to get this rolling.

Actions

Joe Dunfee Feb 18, 2009 4:14 PM

Ok, the "do not prompt" option was the final thing we needed. Problem solved.

Thank you very much.

Joe Dunfee

Actions

4 Replies

Dale Dunn Feb 18, 2009 1:16 PM
Mark Correct
Correct Answer
Joe,

Right-click on the top of the assembly's feature manager tree and "show update holders". These sit at the bottom of the tree and show where every external reference is in the assembly rebuild history. These were much hated before about 2004, because there was no way to hide them, and few uses were known for them. This is one of those uses.

Instead of deleting or reworking your design intent, how about forcing the top level assembly to open the referenced documents as read-only, so that others can edit them? This is controlled by just one of the settings in the "multi-user environment". Read about it in the help. It sounds like something you can use.
Like • Show 0 Likes0
Actions
Joe Dunfee Feb 18, 2009 2:23 PM
Mark Correct
Correct Answer
Thank you Dale. The "Show update holders" is exactly what we needed to track down the problem links.

But, even better that system option, "Open referenced documents with read-only access" should allow us to work on sub.

But we just tested both options above. I.e. we use "show update holders" and successfully remove all of them by editing those parts. We also set the, "Open referenced documents with read-only access". But, these things didn't help us at all. Opening the top assembly, and then dragging one of the sub-assemblies and then saving will cause SW to prompt to save a bunch of other sub-assemblies that have no in-context relation to anything in the top assembly.

For reference, just opening the assembly as "read only" seems to still allow the top assembly to take control of the sub-assemblies so that others can't work on them. So, a simple open as "read only" doesn't help.

Perhaps we either need to give up on the collaboration, or continue to educate ourselves. This is a complex issue, and having less than 100% understanding of it is not really useful.

Joe Dunfee
Like • Show 0 Likes0
Actions
Dale Dunn Feb 18, 2009 3:11 PM
Mark Correct
Correct Answer
There's another setting somewhere "do not prompt to save read-only documents" that is an essential partner to opening referenced documents as read-only. Once you've got these going, you need to get used to using the reload tool to open referenced documents that you need to edit as read/write. This is the price of collaboration.

If you find "collaboration" and "multi-user environment" in the help, it can tell you about those tools, but in 07's help I missed anything about a strategy for implementing it. There may be a guide on the customer portal somewhere. I'm referring you there because we're near the edge of what I know about this. I explored it back when it was new ("collaborating" between two sessions of SW on the same computer), but I've never had an actual need to use it. I hope I've given you enough clues to get this rolling.
Like • Show 0 Likes0
Actions
Joe Dunfee Feb 18, 2009 4:14 PM
Unmark Correct
Correct Answer
Ok, the "do not prompt" option was the final thing we needed. Problem solved.

Thank you very much.

Joe Dunfee
Like • Show 0 Likes0
Actions

How to track down in-context relations in the top level

Outcomes

Related Content

Recommended Content