We recently had to move our data off-site to a new server with a new name and path. I have been able to fix most paths with the untility in Rev. Mgr. Tools. However, we still have a few that are giving us issues. Opening large assemblies takes forever becasue it is looking for the files with the bad link. Is there a way to force SE to skip looking for files and just open the model with missing parts?
This would speed up opening and then we can replace parts as required.
We had a similar situation years ago and used a DNS Alias on the company's internal DNS server to solve the issue. It works as long as the old server has been taken offline. It's basically a pointer in DNS that redirects all traffic from that old server name to the new server name. As long as the file path/structure remained the same it will all work fine without the need to remap anything in Edge. As long as the DNS server(s) are up and running and any changes to them like the DNS alias entry are ported to new servers when they are replaced as well.
Also, I'm guessing you're talking about the utility "Redefine Links" where you specify the old root path and replace it with a new root path?
Also, do you know about the "LinkMgmt.txt" file? It has the following entries:
BEGIN SEARCH PATH
END SEARCH PATH
In between BEGIN SEARCH PATH and END SEARCH PATH you can put the new paths to the files. Be aware that Solid Edge will search the sobfolders of the paths specified and finds the first matching file. Also, it only searches for files it cannot find using it's regular opening process.
Yes, redefine Links is the utility we used and it works pretty well on the whole. I have had good success with it in the past. This time, however, for some reason we have some pesky files that are giving us problems and I cannot seem to get their path corrected. SE takes forever and a day to open the assemblies since it is looking all over for the missing files.
I know about the Link Mgmt.txt file also and planned to go to it next. How much of the path do you need to provide in there? Do I need to define the path all the way to the file level or just the beginning folder to get it pointed in the right direction?
This whole thing has been a mess. I was off for two weeks when they made the data move to Peoria so they have been fighting this stuff in my absence. Also, as expected, it is so darn slow that we may never be productive again. It is simply awful. All I get from IT is that I don't know what the hell I am talking about and that it is not significantly slower than the previous arrangement.
I think we can all agree when we are tuned into the speed of opening files in SE we have a pretty good feel for when things are behaving normally and when they are not. It is a joke how long it takes to open our typical assemblies.
If I could just get SE to open without searching I could do some replacements in the assembly pretty easily. In most cases we have found so far it is typically 5 or 6 files that live on a folder different from where most of our files reside.
I haven't used LinkMgmt.txt for a while but the Help states that Solid Edge will recursively search all sub-folders of what ever folder path is listed so I would only include the path down to sub-folders where SE files reside and avoid going to high such that SE may have to search non-SE containing folders due to the time it may take when opening a file with broken links.
They set up an alias before they moved the servers to Peoria, so I was able to run the redefine links tools before I left for vacation, but we did not know what was still broken until they made the changeover and pulled the plug on the old server. I was gone for two weeks and have been trying to pick up the pieces since I returned Monday.
Editing the link management file solved a lot of our problems today. One interesting thing happened after I edited the file though: We opened one assembly in revision manager and we had a couple of links that were red and showed only the path as far as the folder - no filename. My first thought was that perhaps becasue of the depth of the folders and length of the filename that there were too many characters for revision manager. I did not count characters, but it was pretty long.
However, upon further investigation we found that there was a Pro E file with the same name as the SE file, both with an .asm extension, one folder level above the correct SE file, that SE picked up through the link management path. What is strange though is that the file had an extra ".1" version indicator after the ".asm", but SE still selected it. However, becasue of the extra extension it would not display in revision manager. It was easily fixed, but just one of those curves I did not see coming.
We were hanging onto the Pro E files for no real reason, so we are dumping them out so this does not happen again.
Thanks to both of you for the suggestions today. I think we are back on track except for the speed situation. Things are mighty slow compared to what we are used to.
No one is listening, but it is going to seriously impact our productivity.