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.
Posts
4 comments:
Great minds think alike...Here's a snippet from my script to deal with crashes (of course this only helps if it saves a recovery file) there's more to it but you have my script so feel free to add this to yours.
IfExist %Destination%\%PartFile%%Username%(Recovery).rvt
{
SplashImage, Off
MsgBox 35,, It appears Revit has crashed would you like to open the recovery file?
IfMsgBox Yes
{
LocalFile = %PartFile%%Username%(Recovery).rvt
IniWrite Opened, %UserProfile%\Revit Launcher\RevitLauncherLocal.ini, Local, Recovery
GoSub CheckOpenType2
}
IfMsgBox No
{
GoSub Splash
GoSub CreateLocal2
}
IfMsgBox Cancel
ExitApp
}
Thanks David! The particular instance I mentioned in my post did not produce a recovery file (Revit just disappeared, no warnings). However this is a great little addition and I'll slide it in.
I've been thinking about how the script could detect that the local file on the machine is out of date (needs syncronized). Unfortunately a simple date comparison does not tell the whole story as another user could have SWC'd, thus changing the central file's date & time.
Great post! You bring about a great point that I feel many times has gone over looked or not fully understood. When 2010 came out with the "Create Local" feature I was avid in using it as we had no scripting for making locals. I found myself using the overwrite option often and recently realized exactly what you have described. Too bad I didn't see this sooner, much work would have been saved. Thanks I will spread the knowledge...
I've also had an issue that is similar by way of loosing work and the ability to salvage: On occasion I find that I have deleted something and synchronized with central thus no longer being able to undo to retrieve the deleted object. I have found a solution through the use of another team members local to replace that object that I thought might be worth sharing from my blog http://simpledesignsense.com/blog/2010/03/10/no-undo/
Hi Adam, thanks for contributing to the discussion! There's not much we can do other than really understand the whole process and share lessons learned with others.
Post a Comment