This error message came up for a customer of mine when they were upgrading a Revit 2013 project to 2014 and using Revit Server. The file worked perfectly in 2013, but as soon as the file was upgraded to 2014, they couldn’t save it to Revit Server 2014…the above mentioned error popped up.
So, like I do with a lot of my customers, I had them send me the file so I could test it out on my end. This allows me to test the file using my setup, which helps determine if it’s a file issue, Revit Server issue, or maybe both. Now, you might be asking…”how do you know what issue it is?” If I can replicate the error on my end, it’s likely a file issue or potentially both. If I can’t replicate the issue, then chances are it’s an issue with their Revit Server.
While I was getting the file downloaded from the customer, I had them try another file (different project) and it worked perfectly. Okay, that narrows it down to more than likely being a file issue…but I still wanted to verify that on my end to make sure. Sure enough, I got the file and received the exact same error message when trying to save the file to Revit Server 2014. Autodesk, here we come!
I worked with Autodesk support to get their take on the file. They attempted to do the same thing we did, get the file saved to Revit Server 2014…same error. After they reviewed the journal and log files (which I looked at as well, but couldn’t decipher what was going on) they determined that it was an issue with the project’s permission data. The “short-term” fix was to detach the central and blow away the worksharing…yep, bring it back to a single-user file. Then, once that process was completed, re-enable worksharing. By doing that process, the permission data was stripped out and re-established and the file could now be saved to Revit Server 2014. However, the file was sent over to the development team for them to take a look at what was going on in the upgrade process since the file worked just fine in 2013.
The development team came back and said they found the issue, it was an invalid workset ID assigned to one of the elements. They were able to fix the file by assigning a workset ID to the problem element. They sent me the fixed file and it worked perfectly. And they didn’t sent back the converted single-user file back, they sent back the original file with the original worksharing/worksets. Sweet!
But, I couldn’t stop there….I had to ask the question; “Is this a fix I could have done, or does this issue need to be handled by the development team?” The answer, they had to do it as we “end users” don’t have the ability to assign workset ID’s to elements. However, you might be able to cut/paste the problem element once you know what element it is (by investigating the journals/logs) and fix it that way…
Challenge Accepted!! (when I get time to test it out …)