ORD Drawing Production - Nesting Depth Value 99

Doesn't the associated Saved View take a snapshot of the references so that when changes are made downstream of the container, it is not inherited by the sheet models? Using the Saved View has its advantages and drawbacks, but avoiding drilling down 99 levels may be one of the advantages.

I checked into this issue today, and- after testing some load times both in PW and operating directly from a server partition, I could really see no difference. Such is odd because I respect the opinions of all of you who have contributed to this thread, and I thought I would truly see some differences. I had a similar discussion a few weeks ago with some folks who thought that working on a PW managed environment was much faster than working directly on a server with SSD's. I saw no difference there either. I believe that some other things are going on here.

Best Regards, 

Mark

I may be misunderstanding the issue, but I don't see any undesired nesting coming into play in any of our drawing files. Although the drawing model has nesting of 99 it doesn't actually change downstream nesting levels of any of the references.

Regarding performance, we have found that the second you create a Civil model in your DGN, nesting level limits get ignored on first file open of a session.  It will cycle through ALL references and ALL their references (and even the same references being loaded in different models). This is not specific to drawings, this is more apparent in them because of the additional references they have. It also is more prominent for models with Profile views and 3d cuts because you are adding more reference trees for it to load. It gets worse in ProjectWise because it then also loads different versions of the same file.

The reason it apparently does this is because it needs to load all models to ensure the dependencies and rules all stay intact. I have been debating that why can't it just load what it needs to? The reference manager warns you when you try to detach a file that there are dependencies so it should be able to be "detected". Also, I am of the opinion that ORD should only allow users to build rules to a maximum Nest Level of 1 and there needs to be a change to how rules are built to reference files IMO - why is every instance of a reference detected as a separate object? If this wasn't the case, we could "restore" relationships broken by accidental detachment and ORD would not repeatedly load the same DGNs on file open.

You can see we have been thinking a lot about this haha 

The fact that nesting depth doesn't appear to respect standard controls or limits is an issue, simply because, if we have developed our settings for a nested depth of 2, we aren't expecting a nesting depth of 99. The software shouldn't be overriding the other settings (see Tim's post on this thread).

Nesting that goes any deeper than our desired container model setup runs the risk of a nested attachment we didn't intend.

Not to mention the performance issues as mentioned above and below.

The fact that nesting depth doesn't appear to respect standard controls or limits is an issue, simply because, if we have developed our settings for a nested depth of 2, we aren't expecting a nesting depth of 99. The software shouldn't be overriding the other settings (see Tim's post on this thread).

Nesting that goes any deeper than our desired container model setup runs the risk of a nested attachment we didn't intend.

Not to mention the performance issues as mentioned above and below.