Hypothetically, let's say you have received a file from a consultant, and after reloading you realise it was a Local file, not a Central. Now, your federated model may already have changed the name of the file to match whatever the local was called. Let's say this problem has caused another problem: multiple instances of that same model have been loaded into this file.
If you are using View Templates, only one of these instances will be the point-of-truth for your View Template Revit Link Overrides. Time to get out your magnifying glass and investigate. Firstly, we will create multiple copies of the RVT file with different names, and then use Reload From (in Manage Links) to get these loaded into the current Revit session. This will create a Local alias:
Now, only one of these is the historical, correct link in the context of this federated model. How do we know which one to keep and which ones to remove?
We can use our View Template Revit Link Overrides to tell us... after all, they are the reason we are going through this process, right? We want Revit to 'remember' the overrides we have made in those templates. So let's have a look at the View Template and see what it tells us.
Basically, by reviewing the Custom overrides here, I was able to determine which version of the Link to keep. It just so happens that the correct historical link had:
- a lower number as its instance name (shown above as 149), and
- a lower number as its element ID (450048 compared to 1288492). I found this by using Project Browser, Select All Instances - In Entire Project and then Manage - IDs of Selection
Now, simply Remove the wrong links using the Manage Links dialog, and be aware of not re-linking multiple new instances if you just so happen to get a Local copy from someone in the project team. And remember...
What does Revit Want? Central copies for linking purposes.