Detach a central file - best practice

[Kev_D]

Hey

What are the best practices to follow when detaching a central model? I understand that it is down to what you want as the end result, but is the model truly detached by just clicking 'detach'? You still get errors relating to it being a central file. I read somewhere to really detach a model, you must click 'detach' and 'audit' and then 'discard worksets'. 

What happens when you discard worksets? Does everything on each workset just bind into each view?

[ToanDN]

When you tick Detach from Central it create a copy of the original Central File.  This copy, when saved, is still another worksharing central file, independent from the original.

Are you wanting to make a worksharing file to a non worksharing file?

[Kev_D]

Thanks for that.

Yes to make a non worksharing file. I want to find out the best practice for sharing a central file to consultants. I've been reading different things. Some say to leave as is so they have everything (just send the central file, or just basic detach), and others say to purge, audit and discard worksets. Does discarding worksets just bind everything to the views (basically all VG settings get removed and everything is seen on each view).

[ToanDN]

I have been sharing detached files using the above method to consultants for a long time and they have zero complaints.  Granted our consultants only link our files in their models and don't actually need to open them. 

Do your consultants open the files you sent for some reasons?  Even so, all they need to do is save as the file overwrite the original and tick Make central box from the File Save Options.

Last but not least, I would advise against merging worksets.  Your consultants need your worksets in order to choose relevant ones to open when they link your files in.  For big projects, this is critical.

[Kev_D]

Sometimes they may access them to make visibility changes. We have had to do that with some models that consultants have sent us in the past. Again, it all depends on the project and what you want to show. I get that some consultants do not have proper templates set up and things can be a mess, so that would be the main reason we have had to go into their models.

I'm pretty confident in our template that they would not need to access it.

So you reckon its best to audit, detach, discard and purge? I think its best for this also, as you have a good clean detached file. 

[Anonymous]

Unless your company is worried about digital rights or something (some companies delete all the sheets before sending to consultants)...I just make sure everyone has sync'd, then copy the central over to the share location.  There is no reason to purge, audit, discard, detach, etc..

Now....the only reason I will ever "detach" a consultant's model is if they used "attachment" vs "overlay" and their "attachment" is my model.

[Kev_D]

@Anonymous Duly noted.

I certainly would not go as far as to delete sheets, views, etc. Generally I would not even purge everything. Audit, however, I would, as it does clean the file if it requires cleaning therefore reducing file size.

I was only more worried about the worksets aspect. What happens to the data if they are discarded?

I also want to remove the worksharing aspect.

Although  @ToanDN cleared this up by saying that the new detached file is an independent worksharing file. This is still a worksharing file and gives some errors when accessing it. I've had people call me asking when they open it and the error says it has been moved, which I then say "it is detached.... work away on it!"

IMO, Detaching a file should be removing the central worksharing aspect of the file. 

So when forwarding a model to consultants, my aim would be to remove as much errors as possible.

[ToanDN · Accepted solution]

I emphasize again that keeping worksets intact is more important than all other cleaning, purging, saving, etc... combined.  If you merge them, your consultants have no way to close any worksets they don't want or need to see, e.g. If you have a workset for interior finishes and SMEP need not to see it, they cannot close the workset and have to resort to filters and other cumbersome approaches.

Do not discard worksets.  

[Kev_D]

@ToanDN 

Thank you. That's what I want to hear. My only major concern was the worksets. 

[Anonymous]

Usually I just want to turn off your grids and levels....that is a simple workset to turn off vs hunting down the categories.

Leave the worksets be.

[roshani.dubey]

Yes.

[bheidmousWNHRM]

From my understanding, the best practice for saving template files for worksharing projects where several different discipline templates are intended to be linked and shared vie BIM 360.  To save the files in a way that they can be edited and saved without constant central model errors, the worksets do need to be discarded and and open with Audit is more of an option.  When a new project commences and the discipline model links are created, the standard worksets should be created new.  It's an extra step setting up projects, however but it does make template editing much more user friendly.  So it's give and take really at this point.  Cheers

[RobDraw]

This thread is about sharing workshared projects, not templates. 

[GallowayUS_com_RonAllen1]

If left as links files can be unloaded and there is still visibility graphics and links to control visibility.  Worksets should not be used to control visibility of links. Unloading that workset doesn't' unload the file and it is still resident in memory.

[Kev_D]

The worksets of the link are part of that link. Once the link is unloaded, the ability to change the worksets of that link also gets removed.

I certainly prefer when consultants share their link with Worksets applied as it allows me to control visibility of elements within their model (once shared and linked into ours).

BIM 360 removes the detaching issues anyway. 

[RobDraw]

I avoid using worksets for visibility, too. Too much room for errors. 

[Kev_D]

There is a lot of room for errors across all aspects of visibility coordination. It all depends on how others model and how well they manage their standards. 

[RobDraw]

That's a typical noob response in an attempt to validate a questionable workflow.

[RDAOU]

This whole Post is odd

Detach a Central Best Practice..... for heavens sake Detach comes with only 2 Options!!! I am not sure what Best Practice is being discussed here. A best practice would be asking the recipient what do they need and how they intend to use the transmitted model rather than wondering what might be right and whether it would make them happy or not.

As for BIM 360...No it did not remove detaching issues. Only 20% of Autodesk's clients use the construction cloud...How do you transmit model to those who are not using the construction cloud!!!

1. Download/Save As Local (including all links)>>> Detach
2. Download/Save As Local (including all links)>>> eTransmit

[Kev_D]

No need to waste your time replying if you think it is odd. All it was was a discussion. Don't be so upset about it. 

Post initiated in 2018, when my experience was not where it is now. Did you ever have to learn or were you blessed with the skills when born? Maybe Autodesk could introduce something that removes the ability for one to respond when the post has a solution. 

A lot of our projects are BIM 360 as we promote its use. Sharing the model with non-BIM 360 members can be done very easily. No detaching or transmitting. 

Thanks for your input.