I’m sure you have probably seen this message before:
Can’t edit the element until ‘problemUser’ resaves the element to central and relinquishes it and you Reload Latest

This may be caused by one of your team members not syncing with Central, and then experiencing a crash, or just logging out and going home. Before you send off an angry email, perhaps you could use one of these methods to get rid of the element locks and keep being productive. Method 1 is a bit more disruptive to a large team, while Method 2 is a bit more ‘hacky’. Important: Both methods will mean that ‘problemUser‘ has lost their work and will have to redo it.

So, maybe Method 0 is ‘call problemUser on the phone’ and see if they want to come back into the office to try and sync their work back to Central… but if that isn’t an option, you may have to use one of these methods:

Method 1 – Recreating the Central File:

  1. Notify all team members to Sync with Central and Close Revit
  2. Make a copy of your current Central file and _backup folder and put it somewhere for safekeeping
  3. Detach from Central
  4. Save As Central – overwrite the same file
  5. Notify your team members to open the model again, using ‘Create New Local’ tickbox

method1.png

Method 2 – Using a Known User Name to Relinquish Element locks

First, make a note of the user name that has the lock. In the image below, it is ‘rds check3‘:

c1.png

Open a new Revit instance and set that as the user name in Options:

c2.png

Open the model normally (Create New Local) under that user name, and immediately click ‘Relinquish All Mine’…

c3.png

… and then Synchronize with Central. The element locks should now be gone.

c5.png

In one of the other model instances (ie. your own user name), you can now Sync with Central… (or Reload Latest)

c6.png

… and you can successfully modify the element that was previously locked.

c7.png

As usual, the best idea is to do What Revit Wants and Sync with Central regularly so that lost work is minimized.

If you are using multiple instances of Revit, against one Central file, using different ‘pseudo’ usernames, you may have run into trouble because Autodesk single sign on (SSO) always keeps you logged out in that situation. As soon as you log in, all your Revit usernames get switched back to your SSO username.

Okay, so how can we work around this? Basically, by using psexec to launch Revit using another Windows user. This allows us to have SSO running in one ‘Windows user’ and SSO logged out in the other.

Steps:

  1. Ensure you have psexec available
  2. Make a CMD with this text (for Revit 2015):
    psexec -u OtherWindowsUsername -p OtherWindowsUserPassword -d -i “C:\Program Files\Autodesk\Revit 2015\Revit.exe” /language ENU
  3. Open Revit in current user and sign out of A360
  4. Run this CMD file, and in the new instance of Revit you can sign back into A360

The workaround and outcome is shown in the image below:

 As usual, there may be complications with this method (such as access to different network resources etc), so please use at your own risk 🙂

Revit Wants you to transmit ‘detached copies’ of Central files for linking into other models. If you ignore this and transmit your Local copy instead, Revit always remembers where that instance of the Local file was saved, and it causes havoc in a federated model situation. You can use the free CTC explorer extension to quickly check this:

Or you could use Dynamo with my Bakery package:

 Hypothetically, let’s say you have received a file from a consultant, and after reloading you realise it was a Local file, not a Central. Now, your federated model may already have changed the name of the file to match whatever the local was called. Let’s say this problem has caused another problem: multiple instances of that same model have been loaded into this file.

If you are using View Templates, only one of these instances will be the point-of-truth for your View Template Revit Link Overrides. Time to get out your magnifying glass and investigate. Firstly, we will create multiple copies of the RVT file with different names, and then use Reload From (in Manage Links) to get these loaded into the current Revit session. This will create a Local alias:

Now, only one of these is the historical, correct link in the context of this federated model. How do we know which one to keep and which ones to remove?

We can use our View Template Revit Link Overrides to tell us… after all, they are the reason we are going through this process, right? We want Revit to ‘remember’ the overrides we have made in those templates. So let’s have a look at the View Template and see what it tells us.

Basically, by reviewing the Custom overrides here, I was able to determine which version of the Link to keep. It just so happens that the correct historical link had:

  • a lower number as its instance name (shown above as 149), and
  • a lower number as its element ID (450048 compared to 1288492). I found this by using Project Browser, Select All Instances – In Entire Project and then Manage – IDs of Selection

The above two ‘numerical’ investigative methods are probably not 100% reliable, but they may give you a good idea of which link instance is older in terms of this project.

Now, simply Remove the wrong links using the Manage Links dialog, and be aware of not re-linking multiple new instances if you just so happen to get a Local copy from someone in the project team. And remember…

What does Revit Want? Central copies for linking purposes.

There is no immediately easy way to override the colour of an entire Revit Link. Of course, you can set up a View Template and override all of the individual subcategories, but that can get time consuming when working with many links…

Worksharing Display Mode gives us a quick way of visualising Worksets. What if we put each Revit Link on its own Workset? Then if we set Worksharing Display Mode to Worksets, these Links are overridden with the Workset colours selected in the dialog:

Unfortunately, the Worksharing Display Mode setting is a temporary override (notice the border around the view?), and it will be switched off when we close and open the file. However, the colour choices will be retained. Is there a way we can quickly ‘turn on’ the Worksharing Display Mode for all views in the document? Perhaps this could be done just prior to printing, or at the start of an editing session?

Enter… you guessed it… Dynamo.

I made a node to Enumerate Worksharing Display Modes available, and another one to Set Worksharing Display Mode for View. Finally, I adapted the archi-lab Get All Views node into a List All Views node. Now, we can set them in one click:

And a Screencast:

Each time you print, you will be prompted to “Leave the mode on and print…“, but the colour override will print fine 🙂

Update:
Colours will transfer using Transfer Project Standards, as per:
Transfer Project Standards

If you populate a project with the desired worksets, usernames, and colors you can automatically transfer most of this data over to another project.  Under Manage > Transfer Project Standards, there is a new option for Worksharing Display Settings.

Keep in mind this will not transfer over workset names from one project to another. 

It will however transfer over workset colors, should the same name workset appear in both projects.

Each category has a Show Color column with a checkbox; these are project specific and do not transfer.
Revit 2012 Worksharing Display Modes and Transfer Project Standards – The Revit Clinic

Non-recent comment from Kyle (Autodesk staffer):
Recognizing that Worksets alone were not flexible enough to facilitate productive collaboration in many cases, we implemented Element Borrowing. This enabled the transparent borrowing of elements when a user operation required them to be editable, without the need to explicitly “check out” of the entire Workset that contained them.

So Element Borrowing is really the implementation of Worksharing in modern Revit. Worksets were never deprecated, since many existing users at the time still used them for their original purpose. Even today, we see the pre-Element Borrowing understanding of Worksets discussed and implemented in the market. Ultimately, that’s our fault for not communicating as effectively as possible with the Revit community. 

Check out the whole thread:
Some thoughts on Revit Worksets and Worksharing | LinkedIn

From Daniel Gijsbers blog:
“if you try to open a revit workshared file (central file) with LT it right away makes a copy of the file with LT added to it’s name.

But what is even more surprising it leaves the central file intact. With that I mean I saved the central file in Revit LT and next I open the same file in it’s bigger brother. Big Revit says right away: Would you like to create a new local? In other words, you are trying to open a central file. Revit LT doesn’t throw away the worksets!

When you have opened the file take a look at the worksharing display


Revit LT has created it’s own workset… called Revit LT user”

Read more about the implications of this:
Daniel on Autodesk AEC software: Revit files and Revit LT

Until Revit comes up with some kind of advanced and granular permissions management for workshared files, we are left with a situation that requires best-practice Revit use combined with 100% obedient staff.  If you would like to take matters into your own hands in the meantime, you can use this somewhat scary hack to check out worksets using a concealed user name.  As with many posts on What Revit Wants – use at your own risk!

In short:

  1. Copy the username into Microsoft Word and change it to a different font in this example the font called AIGDT. (which is just associate symbols to letters).
  2. Copy the username (AIGDT font) back into Revit and as you can see Revit just shows it as bullets.
  3. Worksets checked out to that user will appear to others like this:

 
Image and idea by Navid at:
Locking WorkSet with a hidden user name!

There is a nasty little bug that sometimes causes Backups (and any attempted Restore) to fail on a workshared project.  The way to avoid this problem is so simple that it should probably be implemented on all workshared projects in your office:

check Regenerate if view/sheet is not up-to-date.  This will create a thumbnail for the non-opened view to be included with the initial backup version and eliminate the error message when saving the backup version.
via
Cannot Restore Backup Version an Unknown Error Occurred – The Revit Clinic

However – if you have already come across this problem and it is too late to check the above box … you may be able to get the Restore to work IF you reinstate an appropriately named preview.xxxx.dat file into the _backup folder.  Its worth a try if you are struggling to recover some important data.

I just became aware of an issue that I wanted to pass on to you all right away.  Workset1 is special.  It should never be renamed, because it can lead to fairly serious problems down the track, including the This action has caused deletion of non-editable workset: issue.

So you should make it part of your Revit standard that no one can rename Workset1 – ever.

As usual, this is something that Steve already knew, and already told us.  Thanks Steve!

One other habit I have is to never rename Workset 1 because Revit won’t let us delete it. It’s the “original” workset and Revit just doesn’t let us delete it.
via
Revit OpEd: Delete a Workset’s Contents?

An old discussion on AUGI also touches on the issue:

sweiser
2009-04-16, 12:27 PM
I just followed Shruti’s instructions and got the same error. For me it says I am deleting “non-editable Workset ‘Workset1’ ” Any other ideas?

via
http://forums.augi.com/archive/index.php/t-84855.html