I’ve received quit some input on my question on user not being able to connect to the security domain. Apparently, even when only a few users are accessing BO the object file is locked out for users. I also received the suggestion of using only local object file. What is the disadvantage of doing this? As it will avoid users from receiving the disturbing message according the security domain, I only can see advantages.
I also received the suggestion of using only local object file. What
is the
disadvantage of doing this?
The only disadvantage I can think of, is when you use true local installations (so the objects.lsi is on your C drive). Then when you login using a different computer, BO won’t automatically recognize you and all your settings (like whether or not you want a wizard, when to autosave, etc.) are back to default.
In the case the objects.lsi is installed to be used from a fixed (but user specific) place on the network or gets copied from there to your C drive when you log on to the network or start BO, you don’t have this disadvantage.
Hope this helps,
Marianne Wagt-van Loenen,
IDETA, the Netherlands
As Glenn Fredricks stated; the “local” installs of the Objects.lsi file is the
best way to go.
This file can be easily corrupted and the server based “shared” install affects
every user on that server, while the file corrupted locally will only affect that
desktop and not take every user down!
We have done some extensive testing (4.0 & 4.1) on how this gets corrupted. The easiest way to reproduce this is to start up BusinessObjects, login in, become impatient while waiting for a response to the login (or have your PC hang), and kill Bus Obj or reboot your PC. The Objects.SSI file would almost always become corrupted in that situation.
Hope this helps.
Bruce Hinrichs
Schneider National, Inc.
Green Bay, WI HinrichsB@Schneider.Com
(920) 592-2098