Although originally posted in the Developer Forum, I think this can be useful here too:
Since our update to ST9, we have been experiencing some changes in the link management of the files and their drafts, or at least in its behaviour.
In our workflow, all drafts are always stored in a 'DRAFTS' subfolder placed where the parts of the machine are. So for example, the placement of a component along its draft is as follows:
As we move projects from disc to network and so on, 'arbitrary_path' can change, but the relative link between a component and its draft is not changed, at least as far as we don't change 'DRAFTS' name.
We use the default LinkMgmt.txt configuration, so no break link should occur if we just change 'arbitrary_path', since the RELATIVE approach should work fine. In fact, in previous versions of SE, even changing DRAFTS with another name was fine. SE seemed smart enough to find for a link inside a draft in the upwards folder before trying to get the absolute path.
From our experience, SE has lost that 'look upwards' behaviour and, even more, when the RELATIVE paths have not changed, sometimes (not always, weird!) the links are broken and we must make a full re-link.
We have tried a dirty trick in order to get back the 'look upwards' of the past, editing LinkMgmt.txt this way:
CONTAINER RELATIVE ABSOLUTE BEGIN SEARCH PATH .. ..\.. END SEARCH PATH
As you can see, we have added instructions to look in the up folder until two depth levels (sometimes we make subfolders for diferent drafts, so a second level in the tree is useful). To our surprise this works :-D, althought, as I said, nothing of this was ever needed in previous versions. SE managed to reach links placed in upper levels naturally.
Now comes the amazing part of the story: with the LinkMgmt.txt as shown, whenever we try to launch SE and open documents through the API, the whole app gets freezed. No errors, no exception, no messages. SE gets freezed and the document never opens. If we have manually launched SE before, so it's not opened from the API, we can skip the freeze most of the time, but not always.
If we restore LinkMgmt.txt to its default, all works fine.
Conclusion: launching SE and opening documents from the API does not like our 'seek upwards' tricky directives, which in fact work superb when working manually, althought were not never needed in older versions of the software.
The opening and loading of documents it's done by means of the typical API methods:
If it's difficult to understand all this, try to guess how tricky it as until we could define this odd behaviour. Can anyone throw some light over this?
Thanks for your time and patience if you were ever able to get here. Hope this can be useful for someone.
I always thought SE looked down and not up? In that instance I would think the absolute path is the reason it resolves but then I'd be happy to know more.
I was never clear on which directions SE looked for relative paths.
In order for SE to "look up" I always defined the exact, top level, search path that we store our files in and let SE "look down" from there. No tricks or gimics. Using the 3 keywords before the search path prevents unnecessary delay in searching.
CONTAINER RELATIVE ABSOLUTE BEGIN SEARCH PATH k:\cadfiles\CustomerControlled K:\cadfiles\CatalogParts k:\cadfiles\Tooling k:\cadfiles\Product END SEARCH PATH
Note: We are currently testing the new built-in data management tools and our top-level folders are now the life cycle status, as opposed to Tooling or Product, so things are definitely a bit different with ST9.
That approach works, for sure, but we can't use it here.
The fact is that projects are moved in a regular basis: workstations, laptop, network, backups, etc. In short: absolute paths change all the time, and we also try to keep each project self contained in a single folder (except for standar components), so we can move the whole stuff withour worrying about paths.
From my perspective: having a workflow depending upon absolute paths in an era when cloud management is the next step and when we are using the built in API for avoiding any non-creative human task it's just a joke.
Also, absolute search must be quite slow, since the searching speed in a single project will indirectly depend upon the number of projects and, in general, the quantity of information besides the project itself. Mathematically speaking: a crime on efficiency punished by the most basic engineering ethics :-P
The look upwards approach has always worked, although I have never seen it documented. I tried it for ages even changing the subfolder name and you can be sure it always was able to catch links placed upwards. I'm talking about SE since it's version 19 along years. Even now, it works sometimes! I wish I could explain the reason...
Thanks for your interest, I hope this post becomes a rich (an needed) documentation for this stuff.
This isn't an answer, but it's a question on similar lines - I'm trying to remove the 'absolute' search from LinkMgmt.txt (to find out what will break if I copy a whole folder worth of files to somewhere that can't access other network locations) but this doesn't seem to be working. Solid Edge is stubbornly finding the files, grrr.
My LinkMgmt.txt simply looks like this:
BEGIN SEARCH PATH
END SEARCH PATH
To my mind, removing the ABSOLUTE keyword should break the links to files that are in other network locations, but it doesn't. Any ideas why?
Because the file locations are hardcoded into the Solid Edge file - removing ABSOLUTE will not break this hard-coded file name behaviour. All ABSOLUTE will do is allow you to control the order that Solid Edge will attempt to search and locate the files in relation to the other keyword Search criteria.
Master ER# 1304481
Thanks for your answer Dave, that makes sense! Looks like the only way to find out is to unplug the network cable then?
Is the CONTAINER and RELATIVE behaviour hard-coded as well? I deleted them both from the LinkMgmt file and Edge still resolved all my links sucessfully, finding relative link locations before absolute.
Solid Edge is going to do everything it can to try and find your files; why woudln't you want this behaviour? All LinkMgmt.txt should be doing is defining the search order algorithm used by Solid Edge to locate and find files. It should not be used to try to stop Solid Edge from finding needed files.
What is it you are tyring to do with LinkMgmt.txt to stop it from finding needed files? Controlling the search order should be sufficient to ensure that your files are found in whatever location you need first.
Also, make sure you restart Solid Edge after making changes to LinkMgmt.txt.
Hi Dave, I get that Solid Edge is trying to be helpful and I'm sure that 99% of the time I'd be very glad of that :-)
In this case I trying to figure out which links are going to break when I can't access certain network locations - imagine unplugging your laptop from the network and then trying to open an assembly. There isn't a lot of documentation that I can find that covers the LinkMgmt file and I mistakenly thought I could replicate what would happen when the network folders weren't reachable, and then do a broken links search to find out what other files I needed to copy over.
I guess the only way to find what breaks is to just try it and see - that'll teach me to try to be clever :-)