Revit STC issue - Tags of linked elements losing host

I have had this issue on a few different projects so far and it is an absolute nightmare.
(STC = Save to Central)

I will attach a video demonstrating the issue, but in short here it is:

Situation:
Two users are working in a project that has the need to tag elements in a linked file, they both have the hosting file open. This is a common scenario on our large projects where the drawing sheets are in a separate file to the geometry.

Problem:
User 1 creates the geometry in the linked file, performs a STC, reloads the link into the sheets file and tags those elements.

User 2 performs a STC on the sheets file WITHOUT reloading links. The tags sync but the geometry isn't there for them to tag, so they lose their host. (??)

User 1 performs a STC on the sheets file and the tags lose their host. (then they come and ask me why)


Tested with Revit 2013 and 2014. Autodesk support has referred me to this page and said to re-host the tags:
http://wikihelp.autodesk.com/Revit/e...7-BE4B56346DE0


Solutions as I see it are for Autodesk to fix it, by adding the option to reload links upon STC. (possibly per file, so you don't need to reload if your not tagging linked elements)
OR, any savvy API guys out there think they could combine Reload all loaded links + STC into one command?

Video Demonstration:
Attachment 93063

Update: This also happens when elements are mirrored (Since the ID changes)

It isn't so surprising when you map out the logic.

It is an extra task but we just need to reload links before using SwC for links that being tagged in the host. This also affects dimensions that reference linked elements. Short of Autodesk adding Reload Links to the SwC process, which definitely won't happen before the 2015 realease, I'm inclined to think that reload links is best done apart from SwC because you may not want all links to be reload due to the quantity of them and/or the time associated with doing it. I was working with a team that has as many as 25 models linked, reloading all of them would be unpleasant and usually unecessary. It would be much better to be selective about which ones are reloaded.

For now, a team that is going down the road of tagging and dimensioning elements in linked files needs to plan for reloading links BEFORE using synchronize with central.

Thanks Steve,
I agree reloading as many as 25 links would be horrible, but so is re-hosting 50 tags. (Or printing a drawing with question marks)

The implementation would have to be a tick box in the STC dialog for "Reload when syncing" I guess.

Quote:

---

Originally Posted by Steve_Stafford

For now, a team that is going down the road of tagging and dimensioning elements in linked files needs to plan for reloading links BEFORE using synchronize with central.

---

I do not get it. Should we not STC and then reload the links?

No, you need to reload links, then STC.

If other people on the same project have linked elements tagged, and you STC without re-loading links, you get the tag without its host element. The tag then loses it host and cannot be re-hosted en-mass.

Quote:

---

Originally Posted by jagostinho134030

I do not get it. Should we not STC and then reload the links?

---

I am having the same issue.. I have 11 building models linked into one “documentation model.” As the building skin (the skin is several groups that were originally links and then bound (turning the skin into a group)) gets adjusted I lose all my dimensions and tags. ALL OF THEM!!! I have not found a way to fix this. What I have noticed is (after attempting to recreate the same or similar scenario)… in the building model… I select a group or an individual element and activate the move command, if the options bar displays either or both “constrain or disjoin” check box is checked… if I uncheck one or both boxes and move the group or element then STC. When I reload the link or open the documentation model I lose all dimension and tags that were assigned to those or that item.
Anyone have any suggestions on how I can automatically keep those options of “constrain and disjoin” unchecked or any other way to find those constraints and disassociate them with the item I am dimensioning or tagging?
I have tried ungrouping.
I know I can select the tag in the documentation model and find new host but I am losing more than 1000 tags. So this is not an option for us..

Well I think I figured it out!!!! At least for my case. So, I wanted to spread the word in hopes that it might help someone else..
Here are some file set up, need to knows…
One or multiple standalone building models with no annotation… These are linked into a “documentation model,” where all annotation takes place. In the documentation model we use all smart tags and dimension to the linked model. With that said…
Here is the fix…
In the building models (not the documentation model), select the item, items and or groups you need to move or adjust. Activate the “mv (move)” command and see if in the options bar any of those items have the “constrain” box checked.. if yes… DON’T MOVE and keep the “constrain” box checked!! Escape out of that command. Once again select the item or items or group and use the “drag” command to move (not “mv”) them to the new location. Or draw in a line at the desired move location and “align” the item to its new location. SWC. Reload the building model in the documentation model and you should not lose anything associated to the linked model.
In short, when needing to modify any building element (in the building model (not the documentation model)), that has a “constraint” assigned to it… it looks as if unchecking the “constrain” box in the building models will force the documentation model to lose its association to those elements.

We ran into the same issue but some links were map using a drive and not a UNC. We relinked to UNC and never had the issue again.

Quote:

---

Originally Posted by dhurtubise

We ran into the same issue but some links were map using a drive and not a UNC. We relinked to UNC and never had the issue again.

---

That is EXACTLY what happened to us. BTW: when I was in the middle of my nightmare and posting multiple pleas for help every day, you offered this advice: "link files in the central, not from the local."

We now use UNC file paths and we link to the central and all our problems are fixed. In fact, someone restored a link from a mapped drive recently and the problems came right back!

I am still having this issue and we are running on 17.0.1146.0, is reloading the links and STC a accepted workflow?