Tuesday, March 17, 2015

Be Careful Creating a Central File in 2015

A thread at Autodesk's Revit User Community Forum caught my attention yesterday. It seemed as though the culprit was something I've written about before, that user's were accessing the project via different shared resource paths. After digging in a bit deeper it turns out the issue, or at least an issue, is that Revit 2015 is more sensitive to how we navigate to the a shared resource.

This is what happens when I browse to a shared folder via My Computer and click on the Drive letter S:


This is what I expected to see (disregard the project name, I was experimenting with being logged in and out of A360 too):


A clue or warning you can watch for is what Revit displays at the top of the Save As dialog.


If you see the drive letter in the description then you'll likely end up with that as your path. I believe you should only see the folder the central file will be in if you are mapped correctly.

It is my habit to always use Synchronize and Modify Settings before closing the Central File, after creating it. As such I can see what the path that Revit captured is. When I notice that it is wrong, like the first image above, I can fix it, get the correct UNC path recognized instead by taking these steps (see the image that follows too):
  • Close the Central File (after noticing the wrong path reference)
  • Create a local file (before any other users start to work)
  • Use Synchronize with Central
  • Click Browse and click Browse again in the next dialog box that opens
  • Select the Central File by browsing to it via the shared resource path instead, type it in directly if necessary.
  • Click Open
  • Click OK (the correct UNC path should appear now)
  • Click OK (The path is fixed)

If you are creating a central file be very careful about how you browse to the project folder. Verify you have the correct path established before letting users begin working on the project.

6 comments:

Alex said...

Central files can be a hassle for sure.

Danny Jones said...

Steve have they changed this behavior in 2016?

Steve said...

I haven't noticed any change yet.

Danny Jones said...

What's the pro/con of having it UNC vs Drive letter? Currently we're using the Globalscape WAFS system and I'd like to not have to use the SUBST command to map my network drive.

Steve said...

Revit doesn't really care about the drive letter, it is noting the true UNC path. As I understand it, it is possible to map this path through the IP address or the UNC path. When a local file is mapped differently that how the person's, who created the Central File, PC is mapped then Revit thinks it is in a different location.

I suspect that you have to use SUBST command to fake out Revit, to make it think it is seeing the same resource because technically the UNC path IS different. At least that's why I've used that command in the past.

For example a mirrored archive a project can be accessed as if it is live by using it, substituting the path to the archive instead of the real current project path.

Megan Stevens said...

Steve,

I have met you a few times at various conferences, and I was curious if you could help me with this exact issue.

I can not get Revit to recognize the P: Drive on our network. We have replicated data on two sites, and our only road block is the mappings.

Do you know what type of logon drive mapping script we need to write to standardize all our machines?

Thanks,
Megan