"This action has caused the deletion of non-editable workset..."

[twiceroadsfool]

This action has caused the deletion of non-editable workset XXX.

You can click Make element Editable, or cancel. This is happening during a Purge Unused, so im not sure why its trying to delete a workset at all. Its not a view workset either, its one of the model worksets. But, the "Make Element Editable" button just brings up the error again, and it just keeps doing that.

Thinking something got corrupted, i deleted the workset and moved those items to Workset 1. Then i tried the purge again, and got the same msg, but now its saying it wants to delete Workset 1. And it still wont follow through... WTF??

[david.kingham]

I'm guessing you have some nested families, and I'm guessing it's Section Head - Min or something along those lines that causing the problem. It is a bug and there is no way for us to fix it. Either leave it and forget about it or send it to support because they can fix it, talk to Don Falkowski.

[twiceroadsfool]

It ended up being a group definition, which was strange. I had/have a group, that has a nested group in it... But the thing is, i dont know why it was trying to delete it in the first place, since it had 4 instances in the model.

However, it was in the Purge unused dialogue, even though it was placed 4 times.

In any event, it was an insignificant group that i (fontunately) didnt need, so i ungrouped the 4 elements, then right click and deleted the group definition from the Project browser. Once it was ungrouped it let me do it...

[phaedra]

Has anyone had this cause problems with upgrading a project to 2009? I have had this error for months now on a project that was started a release or two ago and is now 2008. I just let it be, but now when I try to open the project in 2009 I get the following error:

"The Central File was saved in a different version of Revit. To be able to work with the Central File, please re-save it using a separate session and a username that has nothing editable."

We had that happen with another project in the office, so we just opened the file under each username and relinquished all and re-saved and it worked. I've done that with this file too but it's still not working, so I've concluded that it must be this mystery "non-editable workset" that's causing the problem.

Thanks in advance for any insight!

[shruti.harve]

This is from Autodesk Support:

"The message you are receiving is an issue that the development team is currently investigating. This error can occur with nested families in a workset environment "

Resolution:

1. Close the Revit application.
2. Place the attached debug.ini in the C:\Program Files\Revit [varies]\Program directory.
3. Relaunch Revit and use the purge command. The unused nested components can now be deleted.
4. Remove the debug.ini from the \Program Files location.

Regards,
Shruti Harve,
Ideate,Inc
http://www.ideateinc.com/educate/index.html

[david.kingham]

You have to be kidding me, I've been asking for a solution for this since 9.0....support really irks me sometimes.

Thank you for posting this Shruti, it works brilliantly

[mjward1]

Someone ungrouped an important group in my project, and it put me in a bad mood.

That's great there's a fix. Wish I knew about this fix months ago though.

Follow up:
It fixed all our non-deletable items and it works great. I recommend this method for those who are suffering with this problem. However, it is serious when it says it will delete the workset....and everything else on it. Kind of a bad side effect.

[sweiser]

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?

[twaldock]

We have had this same problem on a couple of projects. It seems that Revit gets its wires crossed about which worksets certain elements (or nested families/groups) are on - in one case the corrupt elements were flagged in properties as being in one workset, but it tried to delete a totally different "non-editable" workset when I tried to remove the elements.

Thanks so much to Shruti for the "fix", but I wanted to stress how dangerous it is to use this fix if you do not first move everything else from the workset it wants to delete, before going ahead with it - as it gives no warning. In my case, I used "Purge" to get rid of some unused nested groups/families, and watched on screen as it happily deleted a whole lot of very much used elements on screen.

Autodesk really needs to fix this urgently - everyone who encounters it should put in a formal support request so they know how many people it affects.

[luke.s.johnson]

Thanks for the tip.

Had this exact problem and it worked for me.

[james.klatt]

I have seen this error mutliple times, but all of mine are tied to views and I am unable to delete the view. Has anyone run into this problem? Has anyone found a fix? I am running 2009 WU3.

[ryand.220123]

I have been getting this error whenever I try to edit one of the groups in a project. I have deleted all instances of the group but I stil get this error when I try to purge it out of the project browser. Oh and my group has nothing nested in it just some shaft walls and stairs. I tried the debug thing but no luck, any other ideas?

[bholmes]

We had the same error recently on a room group in one of our hotel projects. Two of us worked on it on and off for two days with no resolution. We ended up transferring everything except the bad groups into a new Revit file and remade the bad groups. It was a major PITA.

[Scott Womack]

This is a know issue with groups in Revit 2009. If you have a couple of days, Send the file to Autodesk support and they can fix it, and send it back. Otherwise, there is a debug.zip file floating around in the forums, search for it. I believe it proeides a way to get at the offending group to delete it.

[Krissy.kat]

I have used this process, and was able to get revit to run in the AllowDeletionOfNonEmptyWorkset mode, but I still am unable to purge out, or ungroup or even create an instance of these model groups within the project. I have also attempted to edit and purge the offending groups themselves, once I do that and try to load them back in I get the non-editable workset error once again. This is a file we are linking in from another firm and we believe this workset error may be bogging down the model.

Also, I am curious as to how many "debug.ini" versions there are. So far I have seen this one and the run as 2009. Are there any other debug modes and what are thier uses?

[dhurtubise]

Well since it seems that we can publicly talk about that kind of solutions, here's how to do it:

- Make sure you make a backup of the file first.
- Create a text file, name it debug.ini and save it to the Program folder of your installation
- Insert those 2 lines
[DebugModes]
AllowDeletionOfNonEmptyWorkset=1

Try again.

[Krissy.kat]

My debug.ini file already had this text in it, but I gave it a go at creating a clean debug.ini file with the text suggested by dhurtubise. I am able to run in "delete non-empty workset" mode just as I was before, and there was no change. I still was unable to delete the corrupt groups and still recieved the deletion of workset error. So far since this is a link Im trying to clean up (and not a file with annotation objects and sheets I was trying to save)my work around has been to create a floor plan with unlimited view range and a cut plane above the roof and doing a save to new file. The corrupt model groups are gone in the new file link and all is well. I would however be up the proverbial creek without a paddle if this had been a file where I needed to keep annotation and sheets from.

[tarajofitz]

This problem is happening to me when I am trying to delete a level out of the project. The same error comes up however it lists a workset that doesnt exist:

This action has caused deletion of non-editable Workset ' View "Floor Plan: ROOF PARKING" '

We don't have a workset called "View "Floor Plan: ROOF PARKING"". I have purged all the detail and model groups out of the project. Not sure what to do now.

Tara V.

[Tony C.]

We also received this error/message today. We had received the error previously on the same file, but couldn't find a solution that time and kept working without fixing it. It happed to us only when attempting to perform a Purge Unused, so we were able to continue working,.. but the file remained huge because we couldn’t purge anything.

The background info:
Revit MEP 2010 on Win XP 64-bit,
We are engineering firm. The file with the issue is a copy of the architect's file we use as a background. We deleted lots of items that we don't need to make the file smaller, and then tried to PURGE to actually get rid of all those items.
I don’t believe the offending family was in a group. It likely does have a nested annotation family though.

The Error:
"This action has caused deletion of non-editable Workset ' Family : Electrical Fixtures : nn-Outlet-Duplex '"

Frustrating part #1 -- This family IS IN USE, so we don't even want to delete it.
Frustrating part #2 -- Revit would not let us continue without deleting it, but would not let us delete it either....
Frustrating part #3 – It didn’t seem to matter if the Workset was editable or not. (...stupid enigmatic warning…)

Note that we later realized there were 87 (or 147) instances of this family element. Perhaps if we clicked "Delete" 87 (or 147) times from the warning dialog box then we could have continued.

How we fixed it:
First of all, this is a family that we don’t need to see for our MEP files. In fact, that specific model category is usually turned off for our prints. We have our MEP receptacles visible, not the architect’s receptacles. This allowed us to be a little more daring.
(1) We located the offending family in the Project Browser; selected all instances.
(2) * We could not replace the family, so we deleted all instances of that bad-boy.
(3) Ran Purge Unused again. This time it finally worked(!)
The file was reduced from about 260 MB to 150 MB.


The Debug.ini file also looks useful. (And dangerous, ha ha!) I’ll keep it in mind.

Hope this helps!

-----
Update:
* Oops. I mis-typed step #2 yesterday. The procedure above is now correct.
First we opened the Element Properties for the selected items and tried to replace the family type with a different, but equivalent, receptacle family. Revit didn’t allow it, so we deleted them all.

[twaldock]

I have had this error message yet again - must be about the fifth project to get hit by it.
I am pretty sure it has something to do with shared nested components inside a component, in combination with groups. Was editing a family, renaming, duplicating and/or deleting types for the nested shared family - maybe the new type names I'd created clashed with ones existing in the project; the parent components being part of a group just made it all too complicated for revit to handle?
Will try to track the exact workflow when I get time, then register another support issue with Auutodesk. In the meantime this may give a few clues to someone out there.

[david.kingham]

I always thought it was related to shared nested components too, but then the worst offender only had nested components that were not shared. I believe it was caused by upgrading our template every release, since we have been rebuilding our template every release from scratch there have been no problems.

[Tony C.]

I have had this error message yet again - must be about the fifth project to get hit by it.
I am pretty sure it has something to do with shared nested components inside a component, in combination with groups. Was editing a family, renaming, duplicating and/or deleting types for the nested shared family - maybe the new type names I'd created clashed with ones existing in the project; the parent components being part of a group just made it all too complicated for revit to handle?
Will try to track the exact workflow when I get time, then register another support issue with Auutodesk. In the meantime this may give a few clues to someone out there.

Were you able to see exactly which family was causing the probblem?
As I recall -- and it has been a while since we ran into the issue so I forget the details -- the Revit error lists the family name or the ID of individual elements. You can find the exact elements if you locate it with the ID number.

We only ran into the problem with one file. And it was the architect's file not our MEP file so we didn't spend a lot of time solving it.

Good luck!

[twaldock]

This problem has happened to us on about ten projects so far - at the cost of several hours work to fix each project. I've just tried the solution described above - it usually worked in v2010 and earlier (albeit at the risk of losing half your model if you didn't first move stuff off the non-editable workset).

BUT in v2011 it does not appear to work. When you start up Revit with the debug .ini file in place it gives you the massage about the mode being enabled. But you still get the "no-editable" workset deletion message. I have to admit that the problem was already in the project before I upgraded to v2011, but I hadn't got around to fixing it before the upgrade.
anyone else found the same? If so, any solutions?

NB. More testing showed that the problem was not in v2011. It is just this one project - it could not be fixed in v2010 either. So we have to live with it forever - so I'm still looking for a second workaround. Anyone know the trick for disabling worksharing in a project?

Incidentally, we have also had cases where model objects were reporting the name of a view as their workset - sometimes they could be changed to a model workset, sometimes not

[assinck]

We have the same problem here in RAC2011.

We can not delete groups and families. De known error "This action has caused the deletion of non-editable workset..." appears.
This project will run for some time, probably some years... At this time it is almost impossible to manage the project, we can not use purge for example.
I really could use a solution.

The solution in RAC2010 (below) doesn't work in RAC2011

[DebugModes]
AllowDeletionOfNonEmptyWorkset=1

As 'twaldock' mentions revit gives the massage of debugmode, but it doesn't work.

[adham]

The Debug.ini file worked in 2012 thanks original poster from 3 years ago!:beer: