Salvaging your work

When working with Central files, there’s a common mistake that users can commit which could result in loss of work. Understanding exactly what is happening is of paramount importance and can be the difference between a few minutes of lost work or a few hours.

Saving your work needs to become a natural habit. Lots don’t and then despair when a computer crashes. In most applications, using the keystrokes Ctrl + S saves your active document. However if working on a workset-enabled (workshared) project, only your local is being saved. That’s not so bad, but if you habitually use a scripted solution to create locals or use Revit’s Open dialog to point to a Central file, you can end up losing work in case of a crash.

With a scripted solution, if you run a shortcut to create and open a local file (such as in my previous post), you need to be careful in case of a crash. Let’s say you worked for 4 hours and saved your local 10 minutes ago. Over the last 4 hours you did not synchronize with the central file. So if you crash and run the shortcut as you’re accustomed to, you’ll end up with a new local that has 4 hours of “lost” work. You really need to just open the current local file instead and then synchronize as usual, losing only 10 minutes of work since the last local save. If you encounter a user that ran the script multiple times (happened this week!), then you’ll need to go to the Recycle Bin to retrieve the local with the most info. in it. Check the time saved and the file size.

Even more scary, if you use Revit’s solution, select the Central file (“Create Local” is automatically checked) and you overwrite your local when prompted…well, tough luck! You just erased 3 hours 50 minutes of work. There’s really no fool-proof way to prevent this: you still have to develop a basic understanding of the mechanics of working with workset-enabled projects.

Salvaging your work

Some thoughts about Revit files

So now with the new feature built into Revit that recognizes the “DNA” of a central file and automatically checks the option to create a local file with the appended username, adding the word “central” at the end could actually cause confusion when your local file is named myproject_Central_dbaldacchino.rvt. This is why we’re probably going to stick with a script for creating local files like in the past, so we can control the naming conventions, besides some other benefits. Hopefully we’ll have an even better user-friendly version, which is still in the works.

That brings me to the purpose of this post: Why don’t the developers implement a file extension system that identifies what type of file we’re dealing with? Perhaps .rvc for Central files, .rvl for Local files and leave the .rvt for non-workset enabled files. This would make it totally clear what you’re dealing with, eliminating the need for arcane naming conventions. A unique, easily identifiable icon for each file type would also be a very welcome addition.

Some thoughts about Revit files

The Backup folder

A while back I wrote a post about a problem we had when trying to STC (Save To Central). The same issue re-surfaced again a few minutes ago, and similar to last time, we were a bit baffled. The network wasn't seeing anyone as accessing the central file, yet no one could STC or create a detached copy for that matter! Everyone working on the project (about 6 structural staff) were shown to be accessing some files in the Backup folder.

So we reluctantly asked IT to close out those people from the Backup folder. You know the feeling....you're just not sure if this is going to solve the issue or cause a major disaster! But we had no other option really. Well lucky for us, it worked once more. Everyone was able to safely STC with no loss of work. Now on to some Yoga....

The Backup folder

Who's in the CENTRAL?!

Haven't you ever heard someone yelling that phrase across the office? Well today I was more collected as I tried to solve a problem that popped up in one of our Revit projects. And oh by the way, there are cases where you could work in the central file, but unless you REALLY know all the nuances of worksharing in Revit, I wouldn't risk it (talk to your local BIM Manager for details...)

A user was complaining that he couldn't Save To Central (STC). I went to take a look and found that he was getting a dialog with a Cancel button and a key symbol, saying that the Central is being accessed by someone else (don't you wish it would also tell you the username?). This dialog typically disappears after a while and can pop up if two users try STC'ing or borrowing elements simultaneously, or if your network is really slow. For some reason, this dialog was persisting and would not go away.

My first instinct was to see what the Worksharing Monitor tool was reporting. The tool wasn't installed so first, we saved the local file, exited Revit and installed the tool (by the way, if you have an early build of RAC 2008, this tool will report and recommend that you install a newer build as it is not compatible with the June 2007 build). The Worksharing Monitor reported that two users where working in the Architectural Central file.....both where in the Structural group. Let the blame begin!

A few seconds later, one user dropped off the list and I could swear that the remaining user knew better. So I go to his desk and as expected, he wasn't in it (Revit wasn't even open). I tried opening the central file from this machine and auditing it, but the same dialog popped up. Even a Detach from Central resulted in the same thing. Next I tried to rename the file to confirm it wasn't physically open on some machine and it let me, which confirmed that no one had it open. This started to hint at a network problem.

I called up our Network Administrator (another David!) to see if anyone was accessing the Central file, but no one was. Interstingly enough, the Backup folder in the Central File folder showed up as being accessed by the user that raised the flag the first time, even though he closed out of everything. So David worked his magic and forced him out. We tried opening the Central and....ahhh...it worked! We were able to re-open the local file and save the work back to central.

The Backup folder contains a lot of rws and dat files that Revit writes so it can keep track of permissions etc. You should never mess around with this folder. So if something like this happens in your office, take a deep breath and lay that brick sample down (ouch!) and troubleshoot for any network issues before assuming that the central file has become corrupt.

Who's in the CENTRAL?!