Sorry for the wordiness of this one, I don’t have pretty pictures, but carry on, faithful reader!

Years ago, Autodesk realized that their products would crash, sometimes with little warning. They got smart and began creating a _recover.dwg file as part of their error handling. This worked well, people could open the _recover, saveas, and get on with their lives. Nifty!

Here’s the kicker. Vault doesn’t like your _recover.dwg. Not one bit. Vault considers that file an interloper, a wrench in the works, a fly in the ointment, a pox on its house. Here’s a situation for you:

1. A wildly efficient (probably trained by EE!) Vault-using, data reference loving user crashes C3D for whatever reason. Acad engine asks if the user wants to create a *_recover.dwg. User answers yes. Vault has NO knowledge of the crash, drawing is still checked out to that user. OK so far.
2. User opens up Civil 3D, opens the _recover.dwg and performs a saveas to replace the original vaulted file in the working folder. This should be ok, right?
3. A right-click on the file name in Prospector presents Sync to Project (because the project has references,) and Add to Project (because the file info is different,) but NO check in option. Any attempt to Add to Project results in “File by that name already exists in folder XYZ, blah blah blah.” Essentially, the user cannot check in and overwrite the existing data. Uh-oh. This isn’t good.
4. The new drawing (from _recover.dwg) can be added if the drawing is deleted entirely from Vault. This DESTROYS the versioning, as well as any Civil 3D objects that might be sharing data from within that .dwg file. Bad idea, but maybe…?
5. If you do take that step, and get the drawing back into Vault by deleting the existing instance of that drawing from the Vault structure, you cannot check in any objects that were shared previously because of naming conflicts. The only way I was able to get those objects back in to the Vault Project and available for referencing was by hard hacking the project.xml to remove those item references. IE will show the file very clearly, but is non editable. NOTEPAD shows the file as one long line. This is not for the faint of heart, and could completely hose your project. Ugly, but doable.
6. Here’s the fun part, kids! If you do manage to get that file back in, with the objects now checked in and ready for references, ANY drawing that was referencing the original drawing and objects is now hosed. That drawing cannot be opened, recovered. Nada. Nothing. Zilch. It’s toast. And now the wheels are off the bus, you’re praying LDT still works, and it’s time to think about polishing up the résumé.

Moral of the story? Don’t use that freaking _recover.dwg, it will hose your Vault data. I can only say that I find this interesting since Autodesk wants to push people into Vault from all disciplines, yet one of their major recovery tools completely botches Vaulted data.

I bet this would also happen if you went to the wblock everything to a new drawing in cases of corrupt drawing files. The object handles change and that hoses so much within the Vault Civil 3D shortcuts. If you test this, let me know, it’s on my To-Do list, but I’ve not made it there yet.

Admittedly, much of this is conjecture, and I could be wrong. EE has spoken with Manchester about this behavior, and they agree with my theory. Here’s hoping it can be addressed in a future Service Pack or in 2008.

In the meantime…Don’t use the _recover. Save early, save often, and go back to the Working Folder copy when you do crash.

Based on great feedback, I’ve added a Mail this Article button to the blog. Click the little envelope down to the right here and you can send your favorite civil3d.com articles to your peers and friends easier than ever! Thanks for visiting and your feedback! JW