by Dennis Collin
I have been pretty busy as of late, but I noticed this issue pop up whilst on Cadline support recently. The problem was a user couldn’t create a local file whilst working in a Workshared Project. The answer was to re-specify a Desktop shortcut to use the standard ‘UNC’ path that was setup. This is discussed further below, but other (less likely) options are also mentioned too.
A common work-sharing problem users experience is when the Create New Local checkbox is unavailable when the central project file is highlighted.
Here are 3 of the most typical reasons;
1. Are all users mapped to the central file identically?
For example are the Users using Drive Mapping, IP or accessing via UNC? (if the user doesn’t know then this is likely to be the problem!!)
90% or so of the time this is a cause of the issue. Since Revit saves the location of the central file, it will detect if a user is accessing the file via a different route on the network. This is an easy item to check if you have 2 or more users, for example, where one can synchronize with the central file , the other cannot.
If a user is not able to utilize the Create New Local file function, then attempt to open the central file after browsing to the location in Revit. They will most likely see a dialog similar to the image below during file open:
If they see this message it should indicate how Revit sees the how the central file should be accessed.
You can easily reproduce this issue if you have 2 users accessing a project file. Say they are mapped to the server as follows:
UserX - P:\Projects\ProjectXXX
UserY - \\SERVERNAME\Projects\ProjectXXX
In this example UserX has a mapped drive letter directly to the Projects folder, whereas UserY has the full UNC path mapped instead. If UserX opened and saved the project as a central file, Create New Local would work fine for them. But If UserY then attempts to create a new local file it will be grayed out as the location mapping varies.
The bottom line is that all users need to be mapped to the server location where the central file is stored in exactly the same manner [UNC path, IP Address, etc]. It doesn’t matter which option is used as long as EVERY USER is setup in the same way.
A good fix is to find the file pathing in the central file and copy that path (minus the filename) as a shortcut on the affected users’ desktop. This will then cure the problem.
2. Work-sharing is not enabled in the project file
This is an easy potential issue to eliminate as the potential cause. It's a quick process to check if you open the project and see if Work-sharing is enabled under Collaborate > Worksets. Or see the Work-sharing button is available at the bottom of the screen. If this is greyed out then Worksets have not been initiated.
Another possible cause is a user has reverted back to a single user file (a dialogue box would have been displayed though warning them of this.)
3. Central File Corrupt or Thumbnail Locking Issue
This issue is not nearly as common as the other explanations, but if the user cannot create a local file have them attempt to open the central file.
If they cannot open the central file, have another user attempt to open the central file to rule out possibility number 1. (network mappings)
If no user can open the central file, is it giving an error message? Or does Revit simply appear to be frozen/locked-up?
If you receive a corrupt file, invalid file handle, or past its end message the central file may need to be recovered from backups. This will be discussed in another blog in future.
If you cannot recover the file, contact our Cadline support team who will liaise with Autodesk who might be able to fix it with special diagnostic tools.
Best Practice recommends that new local files are created each day to reduce the risk of file corruption due to network issues. (I personally place old local files in a temporary holding area as they can serve as a potential backup and/or a new central file if desired).
Comments (0 comments)