Linked Revit Structural file

[ededios]

Good day,

Weird thing happening the past two weeks. Our architectural file is a workshared file, we have linked a 3 Revit files, arch, struct, and mech. The structural file keeps unloading whenever a user saves to central, we can't figure out why. No issues with the other Revit files, just structural.

Any ideas on how to troubleshoot this?

Thank you!

[Steve_Stafford]

Hi,

I've been seeing this for some time. I believe this has to do with the local - central relationship and the order in which data is uploaded downloaded to the central file.

If user A unloads a link and saves to central everyone else eventually inherits this condition through their own STC. Later if if User B reloads the file and Saves to Central it is fixed for the moment. Then the next user, User C uses STC and since their local believes the link is unloaded it gets unloaded instead of having the link reloaded. I presume that the central file is receiving the changes from the local file instead of pushing its data set to the local first.

The solution, for now, I believe is:
Don't unload links, manage them through visibility or closing their workset and/or
Manage links in the central file. This can be awkward because if others are working you may end up having to make a local file to save changes.

I really need to spend a little more time researching it and submitting it to support. Perhaps if others have done a bit of research already we can get it documented.

[chodosh]

I've been seeing this for some time. I believe this has to do with the local - central relationship and the order in which data is uploaded downloaded to the central file.


I would concur, here are my observations why:
I had a situation where one user, let's call her Sally, made a copy of a Central file in a state with one of five links unloaded. Just unlucky timing that Sally ran her local file maker at that time when it was in that state. Then, she worked for a few hours, and didn't have the workset open for the link, so Sally never noticed the load/unload status. Someone else came in, John, and made a local copy, opened it up and saw the link was unloaded.

I suspect a third and fourth and possibly more users all did the same, worked for hours that day without noticing at first. John reloaded the link, saved to central, thought he was fine and problem solved. Sally then saved her file to central, and instead of picking up John's fix, her status of the unload took precedence, and the file reverted, which Sally was blissfully unaware was happening. The next time John saved to central, the link unloaded.

All of the other users also loaded it at-will and saw the same thing: it would only stay until they saved to central. This went on for days before someone finally tapped me on the shoulder and said, "Hey, um, we can't seem to keep that link loaded, it must be corrupt." Well, it wasn't corrupt, exactly, it was just the timing. My fix at the time was to have them all save to central and get out of Revit, I sent them to some meeting or another while I worked on their file. Then, I killed all their local copies, archived the central, opened the archived copy DFC, and fixed the link. I re-saved-as back to the original name in the original location and had them re-create locals when they got started in Revit again. All went smooth after that.

I thought once that if the first user, Sally, made the fix, it would stick, and was proved wrong since it seemed to have proliferated across the team: some had it loaded, some did not, too many variables to track. The only fix was to fix the Central itself: fix the point of origin (in this scenario we made new locals daily), solve the problem.

I ended up tracking down the original user who unloaded the file and had a convo about load/unload and discovered they'd missed the training on Open/Close worksets. We went through it together, had a team chat, and didn't see this come up again until I forgot to load a new file Absolute to a mapped letter-drive (sorry guys, I admitted to that one being my mistake).

I agree with Steve, and recommend using Open/Close Worksets and/or VG before Load/Unload in a worksharing environment.

What I am not clear about is how there is a precedence by order of events and why it seems it cannot be corrected from Local to Central when there is another Local already in play. I'd be curious to know if there is a rational explanation about the precedence of what I would call the "first state local" over the second, third, etc.

HTH,

LC

[ededios]

Steve, LC ~Thank you!

We had a hunch that could be the scenario but it didn't make sense to me. Now reading it in your posts it's clearer. Our standard is to manage our links by worksets and visibility, but I'll have to sit with the team and figure out if they have been unloading the file.

If that isn't the case, I'll re-post.
Thank you!

[Steve_Stafford]

I've been meaning to run a test with multiple user but every time I'm in a position to do it other stuff intervenes...

I believe that a local can update the project if they STC AND all the other users then reload latest instead of saving to central so that the change at the central file can be pushed to their local files. Problem is that most just hit STC and that seems to push changes first or at least before pulling the linked file change in. Until I can test it with a half dozen users I can't say for sure... You two have half a dozen users kicking around right? Run the test for me? :smile:

[twiceroadsfool]

The easiest way to get around this, ive found... Is that in a workshared project i have a policy with project teams that NO ONE goes in to the Manage Links dialogue. Since we put all of our links on their own worksets, if an end user wants to not see the link or not carry the weight, they can unload the Workset, as Steve mentioned. Now, it WILL *appear* unchecked in manage links when the workset isnt loaded, but it IS still- in fact- loaded.

But, if they unload the workset, it wont be an issue with the other users...

[ededios]

The easiest way to get around this, ive found... Is that in a workshared project i have a policy with project teams that NO ONE goes in to the Manage Links dialogue. Since we put all of our links on their own worksets, if an end user wants to not see the link or not carry the weight, they can unload the Workset, as Steve mentioned. Now, it WILL *appear* unchecked in manage links when the workset isnt loaded, but it IS still- in fact- loaded.

But, if they unload the workset, it wont be an issue with the other users... That makes sense, I hadn't thought that far ahead yet. Thank you! I'll be implementing something similar while we aren't sophisticated Revit users :Oops: but I didn't say that.


I believe that a local can update the project if they STC AND all the other users then reload latest instead of saving to central so that the change at the central file can be pushed to their local files. Problem is that most just hit STC and that seems to push changes first or at least before pulling the linked file change in. Until I can test it with a half dozen users I can't say for sure... You two have half a dozen users kicking around right? Run the test for me? :smile: So I only had 4 users, and we unloaded and reloaded from different local user files. Did STC and RL and the linked file was unloaded or reloaded depending on however the last STC set it up, which is what I expected.
So this didn't help me. My Revit link is unloaded every time anyone does a STC, it seems like a default setting. Is there something specific or a different way I should run the test? I can have 6 users if that's what it takes.

Thanks so much for you help!

[Steve_Stafford]

No...six was just a number I picked out of a "hat". :smile: It would seem that this behavior is "wired" in. We'll have to run it by support to see what they say. We'll probably learn it was done to "speed" up STC, or some such. So for now if "we" follow Aaron's rule we'll be right...

[twiceroadsfool]

While this may seem coincidental (and turn out to be false) ive also found there seems to be a loose correlation between this issue, and workstations that push the envelope on running out of memory and fatal erroring.

It is probably just the additional information of pushing the Linked Files *status* to the local users, but i think it contributed to the issues. Atmy last job we had a large Revit project, with 13 linked files (6 arch, 7 struct). Before we went to the *workset only* method, if people loaded and unloaded the links, STC would take FOREVER, and would also fatal error and/or crash out a lot of times. The problem by and large went away, when we went to the "no touching the manage links dialogue" set up...

[twiceroadsfool]

I've been meaning to run a test with multiple user but every time I'm in a position to do it other stuff intervenes...

I believe that a local can update the project if they STC AND all the other users then reload latest instead of saving to central so that the change at the central file can be pushed to their local files. Problem is that most just hit STC and that seems to push changes first or at least before pulling the linked file change in. Until I can test it with a half dozen users I can't say for sure... You two have half a dozen users kicking around right? Run the test for me? :smile:

Steve-

Ive tried something similar, and you may run in to the following: If user 1 unloads a link and hits STC, and user 2 still hsa the link loaded and tries to RL instead of STC, they may get the message that there is unsaved work in the file that must be Saved to Central. Im not certain though, as im currently not in a worksetted environment...

[ededios]

Steve-

Ive tried something similar, and you may run in to the following: If user 1 unloads a link and hits STC, and user 2 still hsa the link loaded and tries to RL instead of STC, they may get the message that there is unsaved work in the file that must be Saved to Central. Im not certain though, as im currently not in a worksetted environment...

No message, when user 2 tries RL after user 1's STC, the link is unloaded. Did it yesterday.

[Steve_Stafford]

It seems more likely that it is "wired" this way now. Off to support with you all! :smile:

Aaron...just noticed your new email address! Wayne stole you?!? Hmmm...details in a pm please, congrats :beer:

[twiceroadsfool]

LOL, PM sent... It wasnt a theivery...

[chodosh]

I think Aaron may have a point related to "tired" workstations, VM, and worksharing contributing to the "state" of Unload/Load for any given linked RVT. In my long-winded anectdote did I forget to mention that our session times were on average around three hours max before we got our first "low virtual memory" warnings? Silly me... Forgot all about that. ;) I think you're maybe on to something...

-LC

[twiceroadsfool]

I may not have been clear... Im not saying the *tiredness* of the machine is whats CAUSING the loading/unloading... Im saying if you have machines that are pushing the envelope on system resources as it is, having to reconcile the link reloading and unloading may be causing more "low memory" crashes.

We had users everytime they STC'd, ten 20 meg links would unload or reload. Im sure when its reloading, that must bottleneck the computer. Its all *butt dyno* but a lot of those issues went away once people stopped messing with the Manage Links dialogue. :)

[chodosh]

Thanks for clarifying and I actually was oversimplifying, good catch. :Oops: I really lumped it into a way too generic description, sorry, guys... Tiredness really is contingent on a lot of things (myself included, apparently). The recent whitepaper called it "connected network size." Link location, size of link, number of links, etc. all has a part in it. I guess that's what I meant, and what you're saying is that the connected network size is a factor at play here.

[Edit/anectdote: I had a knock-down-drag-out argument with one of our cad specialists a few years ago about why you shouldn't use manage links like reference manager... I finally got it through everyone's head that the two were not the same animal, and once we did, we saw these issues go away, too until we swapped an IP address out on a server...]

[ajayholland]

For those following this thread, please see my recent post - Linking Local Files.

~AJH

[Scott Womack]

For those following this thread, please see my recent post - Linking Local Files.

~AJH

Jay,

Your link does not automatically come up, but I found it by searching the forums. Thanks

[ajayholland]

Your link does not automatically come up...

Linking Local Files

Scott,
Fixed. Thanks,
~AJH