I know for whatever the reason, Bentley recommends NOT storing the user preferences on the network. Our company does do this so that you can go to any machine/office and pull up your preferences without having to setup everything again. My question lies in what is the major drawback to storing it on the network? I recently updated my machine to SS3 and now it takes forever going in and out of files and the icons at the top flash on and off the whole time it is loading a file. My button bars occasionally move around on me also which is really annoying. Also what are all the xml files that are in the directory with your user preferences?
Thank you.
You still can ensure that the user always has it's settings by moving the default storage from <user>appdata\local\... to <user>appdata\roaming\...
We even store the preferences at a number of our customers on the network (for decades). We haven't seen problems at most of them, and the only customer where we're facing problems has some other network problems too. At those customer we successfully tried setting the preferences into the roaming profile. Thus it is accessed locally, but synced with each machine.
Nevertheless before we're going to tell (the rest of) our customers, that we need to change their configuration, I would even be happy to get some additional information (if any).
For the XML, it is a useable way for storing information that might change their structure. While the old upf files are storing data very efficiently, they have problems when the underlying structures are changed. In best cases the previously not contained information is set to some initial value, in worst case, the programmer is not aware, that those informations are stored within the upf (i.e. mdl dialog positions and options) and changes to the underlying structure of a single app are leading to crashes of the whole system. So the Pro of an XML is, that the parser is not neccessarily in need to asure a bytewise alignment of a special structure, so older versions of an app will not by fault use the next (ie. double) value for something it was never thought of. Changes to the XML structure are reflected by named content, and therefore might not be misinterpreted.
The Con of an XML is that you need a lot more memory, not only the stored names, but even the values are leading to larger files. Beside this, parsing an XML is not as fast as a simple access into a structure. So while a lot of the old upf content is kept in the binary data format some of the newer and additional infos made their way into XML files. I think they are even not so often saved as the upf itself, but that's an expectation, I never checked this. While the size of the whole prefs should not be a problem for current systems (normally the system cache should be enough for direct access), concurrent access to the same files over the net might become problematic.
Michael
We are running a mixed XP and windows 7 environment so moving the storage location to appdata\roaming isn't an option unless you know of a way to do this in XP.
It seems like it makes an xml file for each project that is opened by each user so you can end up with quite a long list of files.
We have noticed throughout the years that over time the UPF gets quite large (over 800k) and it becomes less stable so we have always made a backup and just replaced the larger file when needed.
Easiest way around different versions is to use a custom location for your user files. The way I usually do things is to have a c:\Apps\Users\<username> location and copy files from here to a network storage location via login script or via the hta files I use to control my builds. This way directories can be created the first time a user logs in and have the new files set up and then backup. If a user moves to another machine they simply get their files copied down when they login. I've found this an easy way to manage things and also gives me a chance to keep an eye on ucf files as well as check out any corrupt user files.
Marc,
Windows knows the %appdata% variable in each version since Windows2000.
Beside this if you have a look into the msconfig.cfg then you will find the following:
#----------------------------------------------------------------------## The default is to use a completely local (non-network) installation. # If you want it to be possible for your MicroStation settings to be part of# a roaming user profile then consider this alternative value for# _USTN_HOMEROOT:## _USTN_HOMEROOT : $(_USTN_UserAppDataPath)##----------------------------------------------------------------------
So you may choice between %appdata%roaming/... or use the above for your needs
The size of the upf grows with each application that uses UI ressources (ie dialogs) when those are opened for the first time. MicroStation than saves positions and (sometimes) options set by this dialog. With the years, the chance grows that you opened up a lot of dialogs just to have a look what has changed. So the file grows. Beside this there might be situations where the same app has changes that make such a dialog become another internal ressource-id. After this, the old information is kept forever while the new one changes. In worst case the identifier of a whole app changes, and so all ressource informations are stored completely twice. This is even one reason why it is not suggested to keep the upf when it comes to a new (major) version.
HTH Michael