Historically Autodesk has promoted the idea of creating a new local every day, or at least every time Central File Maintenance was done. This was more a reaction to corrupted central files, mostly (I believe) caused by older and very slow networks and older versions of Revit. With newer versions of Revit and gigabit networks, the need is really just not there I think. In addition, there is certain information that is stored in the local file and thus lost with each new local.
• Current Workset is lost with each new local. If the last person to STC happens to be on a funky workset, then everyone starts on that workset with the new locals. Even if the new locals default to Architectural for the workset (the logical default) this can be frustrating for someone who is working only on the Finishes workset, for example. They have to remember to reset it after every new local.
• Opened worksets are lost with each new local. You can configure your local to open with certain worksets not loaded at all, which can REALLY speed things up. Unloading MEP when you don’t need it, or Site, is really helpful. But you have to reset what worksets are loaded with every new local.
• Startup view is reset. If everyone uses a simple view to SwC then at least file open isn’t slow, but it forces every user to then switch to a meaningful (for them) view.
• Browser Organization choices are lost with each new local. We aren’t using Browser Org much yet, but if settings are lost regularly it may never get used. And not using it means more time and frustration due to ever larger view and sheet counts.
Thus there is an argument for minimizing how often you create new locals, doing it often enough to minimize problems, and no more.
My thought is to do this as standard practice
• Central File maintenance is done weekly. New locals are NOT created, maintaining user settings. The Central File will still benefit from regular Audits, and when a user opens their Local and Reloads Latest, and data fixed by audit will flow to them.
• At project milestones the Central File is created new, and all users create new locals. This provides some of the extra benefits of new files (central and locals benefit) but spreads it out a little more.
• On really large projects (Redmond sized) new centrals and locals might need to be done monthly, but probably only during CD phase, or perhaps starting late in DD.
• If there is a problem with the central file, then new locals are created after maintenance, as needed.
• It may also be that we can look into better defining our Archive procedure. We of course need milestone archives, but weekly archives may be a bit redundant in that we are also backing up the central file, which effectively creates an archive. And Revit creates archives automatically, that is what lives in that folder with the same name as the central file. If we can save some time that is currently spent on this, and apply it to addressing warnings on a weekly basis, I think we will find that our models actually work better than ever.
So, anyone have any thoughts? Have you seen problems recently with not creating new locals after doing a central audit? In THEORY if the audit fixes something in the central file, the local user should get that updated via Reload Latest prior to their own SwC executing, so it should not be possible for a corrupt local to re-corrupt a central. But it might make sense to do a Reload Latest first thing after Central File Maintenance, so you aren't working with that kruft up until you SwC.
More than anything I am curious how many people are still doing daily new locals, and how many people have abandoned this. And for the latter, do you feel like your frequency of corruption has gone up as a result?
Thanks!
Gordon
• Current Workset is lost with each new local. If the last person to STC happens to be on a funky workset, then everyone starts on that workset with the new locals. Even if the new locals default to Architectural for the workset (the logical default) this can be frustrating for someone who is working only on the Finishes workset, for example. They have to remember to reset it after every new local.
• Opened worksets are lost with each new local. You can configure your local to open with certain worksets not loaded at all, which can REALLY speed things up. Unloading MEP when you don’t need it, or Site, is really helpful. But you have to reset what worksets are loaded with every new local.
• Startup view is reset. If everyone uses a simple view to SwC then at least file open isn’t slow, but it forces every user to then switch to a meaningful (for them) view.
• Browser Organization choices are lost with each new local. We aren’t using Browser Org much yet, but if settings are lost regularly it may never get used. And not using it means more time and frustration due to ever larger view and sheet counts.
Thus there is an argument for minimizing how often you create new locals, doing it often enough to minimize problems, and no more.
My thought is to do this as standard practice
• Central File maintenance is done weekly. New locals are NOT created, maintaining user settings. The Central File will still benefit from regular Audits, and when a user opens their Local and Reloads Latest, and data fixed by audit will flow to them.
• At project milestones the Central File is created new, and all users create new locals. This provides some of the extra benefits of new files (central and locals benefit) but spreads it out a little more.
• On really large projects (Redmond sized) new centrals and locals might need to be done monthly, but probably only during CD phase, or perhaps starting late in DD.
• If there is a problem with the central file, then new locals are created after maintenance, as needed.
• It may also be that we can look into better defining our Archive procedure. We of course need milestone archives, but weekly archives may be a bit redundant in that we are also backing up the central file, which effectively creates an archive. And Revit creates archives automatically, that is what lives in that folder with the same name as the central file. If we can save some time that is currently spent on this, and apply it to addressing warnings on a weekly basis, I think we will find that our models actually work better than ever.
So, anyone have any thoughts? Have you seen problems recently with not creating new locals after doing a central audit? In THEORY if the audit fixes something in the central file, the local user should get that updated via Reload Latest prior to their own SwC executing, so it should not be possible for a corrupt local to re-corrupt a central. But it might make sense to do a Reload Latest first thing after Central File Maintenance, so you aren't working with that kruft up until you SwC.
More than anything I am curious how many people are still doing daily new locals, and how many people have abandoned this. And for the latter, do you feel like your frequency of corruption has gone up as a result?
Thanks!
Gordon
Comment