Detach from Central versus Save As - Make this a Central Model after Save

Both techniques allow us to create a new central file from an existing file that has enabled worksets already.

Save As - Make this a Central Model after Save - respects the Edited By information the project has stored. This means if other users have borrowed elements then you'll find those users among the Owner/Borrower column in the Worksets dialog after creating your new central file.

This distinction means it may be possible (though unlikley) to allow users to synchronize their work with the new central file. They'd have to use the Browse button in the Synchronize with Central dialog to point Revit to the new location of the central. I used italics on may be possible because there are so many variables that could prevent it from succeeding that I don't want to provide false hope. If people have not continued to alter or create new elements in their own local files, while this new central file is created, then it may be possible, worth attempting perhaps if you are in some sort of recovery mode.

Detach from Central - completely severs the relationship the file had with the file it came from (usually a central file) and any local files that may exist, as well as ALL ownership information (stored in Edited by parameter). It is a fresh start, utterly.

Btw, this post was prompted by a question at RFO this afternoon. It became evident that this subtlety is something I've not written about, I thought I had.

Our Revit Username and Signing into A360

When Autodesk began introducing Autodesk 360 based tools and services they provided us with a place to sign in to our account within Revit too. We can sign in via the Info Bar.

Regarding using worksets, when we are using Revit 2014 we can sign in to our A360 account and it leaves our current Revit username alone. When we are using Revit 2015 logging into A360 will attempt to change our username to match our A360 username. If we are already working in a Local File with a different username we'll get this warning message and signing in to A360 fails.

If we are working on a project that doesn't use Worksets we will be able to sign into A360 but it will change our username in the process.

If we attempt to open an existing Local File later we'll encounter this warning.

If we intend to work on a project, that uses worksets (as many of us do), then we need to make sure we've already logged into A360 before we create/open our Local File to avoid this issue. In Revit 2015 we can sign into A360 via the Options Dialog too.

I'm making a habit of checking my username before starting any work AND logging into A360 first if I intend to use it. That's the tricky part, will I and when? How many people this affects right now compared is another question. The concept of Autodesk 360 poses EyeTee with an interesting problem, creating and managing separate user (other than their own domain) accounts at Autodesk.

Username and Local Files

Revit knows who we are based on a simple piece of data, the Username entry here (Application Menu (Big R) > Options). That is usually defined by who logs on the computer. If we log on our computer, then open Revit AND change the Username...Revit preserves this alternate username until we change it again. If we never change this value then Revit just uses the computer's log on username identity. When we change it Revit captures and preserves it for this particular person's log on credentials on the computer.

Using Worksets (Worksharing) this username provides our unique identity to Revit, the Librarian (not to be confused with the TV show or movies). We can't just arbitrarily change our username while we are working in our Local File. If we do that we'll be greeted with an unpleasant message when we attempt to use Synchronize with Central.

We can become convinced that changing the username is permissible because Revit doesn't complain until we attempt to use Synchronize with Central. It's also easy to think it is reasonable because when the file contains changes that have not been synchronized yet we see this message when we attempt to change the username. When Revit complains and offers the reason that changing the name isn't going to work it implies that there might be an acceptable circumstance.

Fwiw, we CAN change our username freely if we are working in a central file (discouraged). However we won't find that very fulfilling if other users are also working on the project via their own local files. We'll be advised by Revit that it is necessary to use Save As to create a our own Local File first, when we use Synchronize with Central.

We CAN assume any username identity, we just have to change the Username parameter before creating a new Local File.

Damn Revit's Worksets and Worksharing features are fussy!

Local Files - How Often?

Various versions and years have intervened between now and when I wrote these earlier posts.

• Worksets - Take Me to the Library
• Central File in Four Easy Steps
• Local Files - How, How Often and Where?
• Which One STC or STC
• Why a Local File?
• Workset Terminology - Quick Reference
• Revit Worksets 2010 - Local Files
• Stand-Alone File - Central File - How can I Tell?

I recently responded to a query about how often local files ought to be made with this:

I think that new local files should be created each morning and used throughout the day. The next morning should repeat the process. The current solution implemented in Revit supports this thinking by allowing people to easily create a new local (by default) and append a time/date stamp to previous local files when creating a fresh one each morning. For a little history (my own perspective):

My original reasoning for new locals each day years ago was never about corruption (the query suggested that new local files were necessary due to frequent corruption) but about faster loading and not having to remember to use Reload Latest or wait for that either. Opening a central and doing Save As back then meant waiting twice for the files to open (still does now technically). Going back a little further even (for me) the practice of copying the file and pasting it instead of "open/save as" was about "faster" too.

Sporadic team involvement meant inconsistent local file "sell by dates". Mine was current but "Joe’s" is three days old when he opens it because he’s been out of the office for the last two days. If he starts in that file he’s got two day's data to "Reload Latest". If he creates a new local he’s in sync within the window of other people working "today", between when they started and he arrived and started...pretty close to in sync.

File corruption that I encountered from time to time "went away" when people made new locals each day too. Happy coincidence, definitely. Necessary? I don’t know, but it worked to resolve those situations. The corruption probably had more to do with inconsistent participation and "sell by dates" out of alignment than the central/local file arrangement itself. In the end, it was easier to "eat an apple a day" (make a new local) than to wait and see if the issue would arise again.

Since the addition of the new local file option I’ve abandoned other "custom" local file techniques but I still create a new local each day, it isn’t any slower than opening an existing local file and I don’t have to remember to use Reload Latest. I am getting older and my memory isn’t what I remember it to be.

Now where did I put my cane and glasses?

Synchronize with Central - Twice?

I frequently work with my computer connected to a client network without actually having it added to their domain. This means that we map the computer to a shared folder by entering the path and supplying the correct credentials to access the resource.

With 2011 I'm seeing a recurring theme where I must synchronize with central (SWC) twice to actually commit changes so that the other users can see them with Reload Latest. In the same way this afternoon I found that a user needed to double their SWC so that I could see their changes.

Just to add another wrinkle to the situation, the class is a mixed XP and Windows 7 operating system environment, some laptops using each. Their computers are mapped to the network as members of the domain. I'm not sure if these conditions have anything to do with the double SWC or not but it seems to be recurring when I am connected this way. Any corroboration from readers?