Limit to number of files in Project Navigator?

[mbabich]

Hi Everyone,

Does anyone know if there is an unspoken limit to the number of files Project Navigator can deal with?

We currently have a project with 975 drawings in it and are experiencing wierd XRef path issues.

To be fair, this project was copied, renamed (client rebranding request) and repathed. Next it was moved from our main office server to our satellite office server. The share names and assigned drive letters to the shares are the same, so when the project was opened in the satellite office, there was no request to repath the project.

The issue is when a Sheet drawing is saved as a View drawing. The staff working on this project insist that they have to do this to make things more clear and efficient. Once the View is closed and reopened, the Constructs and Elements are not visible. However, the path is actually correct. The XRef Manager reports that the file is not found and the Found At field is blank. Clicking on that and navigating to, esentially, the same location, reloads the XRef and then it's fine from that point on.

I used Reference Manager to double-check the drawing and image paths and they are all correctly pointing to the local server.

Let me know if you've experienced this problem and whether there is a solution to it. Also, if you are aware of any magic number of files where Project Navigator starts to wig out.

Thanks in advance,

Mb

[David_W_Koch]

I cannot comment on a maximum file limit over which Project Navigator does not work properly, but I would question the reasoning behind opening Sheet Files and saving them as View files.  I am not sure how that makes anything more clear or efficient.  It is certainly not the way the Drawing Management system was designed to be used.  View files are where the Elements and Constructs needed for a particular item to be shown in the contract documents are assembled, and annotation added.  A named model view is created and used to define the extents to be shown when that view is placed on a Sheet file.

I did try to save a Sheet as a View on two simple sample projects, one with full external reference paths, and one with relative external reference paths, and neither lost the external references.  Perhaps it was a combination of doing this and the transfer between servers that caused the issue.

[mbabich]

Thank you for responding David.

I am well aware of the Construct/Element to Views to Sheets concept in Project Navigator and I am constantly informing my users of this concept to reinforce this behavior. I too, was wondering about the efficency and need to save a Sheet as a View, but didn't want to get into the reasoning behind why our remote office felt that this was necessary. This was partly because they had alredy completed this for several drawings already and I didn't want them to go back and redo the work. The project was on a tight schedule.

Anyway, I opened a case with Autodesk regarding this issue and the result was corruption at the Construct/Element level. The tech cleaned the affected Construct/Elements and the problem went away.

The bad part about this is the number of files that need to be cleaned. So that raised the question of why those files were corrupt which was answered with a multitude of possible causes.

My own observation is that, at least in my world, drawing corruption is happen a lot more these days. I'm concerned that the never ending speeding upgrade train is causing more harm than good. Perhaps Autodesk should stop that train for 2 or 3 years and work on the compatibility of the .dwg file. Again, in my world, I have to use the Recover command nearly every day to correct issues like this.

Mb

[gpuerini]

The project I'm in has about 4000 constructs/views/sheet, without major issues.
It does sometimes takes forever to open ACA, since project navigator has to process them all to some extent.

[leothebuilder]

I you have a lot of issues with corrupted drawing files I believe that is probably caused by your users rather than Autodesk.

Copy and paste is probably the main culprit.