There appears to be a small problem deploying the DBISam Server in Vista and
Win7 machines where UAC is enabled and the executable is deployed in
"Program Files" folder

The main problem is that the log file is in the same folder as the
executable folder and the trustinfo for the executable is :
<requestedExecutionLevel level="asInvoker" . When attempting to run it as
usual, Windows just displays a message "DBISam Database Server Has Stopped
Working" and the server will NOT start. When "Run As Administrator" it works
fine but a lot of end-user will not know how to resolve this without
contacting us first.

I belive the only problem is that the app cannot write to the log file in
the Program Files folder with this executation level. All data, log, config,
ini etc are now meant to me moved elsewhere with current versions of
Windows. Is there any chance of moving the log file to another folder like
ProgramData etc in the future ? This way the server can still be installed
in Program Files folder and run asInvoker without any problems. I think with
this change, theres also less chance of issues cropping up with upcoming
versions of Windows.

Alternatively if the server needs to be run as administrator, maybe the
manifest trustinfo should be upgraded to : level="requireAdministrator".
This way the server will always run at the correct execution level without
any problems. But I still think the Log file needs to be moved eventually.

Just wondering how to others handle this ?

Regards
Gregory Sebastian

Gregory Sebastian wrote:

> There appears to be a small problem deploying the DBISam Server in
> Vista and Win7 machines where UAC is enabled and the executable is
> deployed in "Program Files" folder

> Just wondering how to others handle this ?

Part of this is the age of the app as it shipped much before Vista.

I don't know if Tim has any plans to change this around (a la EDBSRVR).

There is a fairly significant potential to break existing installs
where dbisam already has been deployed so now the code would need to do
something like "if local settings exist use then otherwise goto common
folder". Not difficuly but will take some time and testing, etc. Number
of people are likely running DBISAM from a network share which does
complicate matters as well.


I work around this in one of 2 ways:


1. Install the app, including DBISAM, somewhere else. Like c:\myapp or
such.

2. If it is going to program files then have installer set the folder
permissions (program files\myapp) to write/modify for all users.

Raul

Putting ini, cfg, data etc with the executable folder was a practice we all
did from the days of Win95, 3.1 and even DOS before the registry existed. It
was perfectly fine then but not quite with XP and espiecially not since
Vista and UAC. The release of Vista & UAC has tripped all of us up. I
remember reading some M$ documentation recommending that all program data,
cfg, ini etc NOT be placed with the executable but be moved to new more
appropriate folder/ registry locations. The logic i guess was to separate
the program files, dll, doc from the data files that needed frequent
read/write. Users could then better manage folders, permissions, backups
etc.

So prior to the release of Vista/UAC, a lot of us were forced to "bite the
bullet" and move all our ini, cfg, data etc so that Vista/UAC will be happy
to work with our apps.  I really think the days of putting the data files
with the executable are numbered. At the risk of annoying alot of other
developers who have already successfully deployed their DBISam server with
the current setup, I still hope to convince Tim to think this through.

It looks like the DBISam server needs read/write access to the log file all
the time. With the trust info set as "asInvoker", DBIsam server fails to run
"out of the box". It will only run with some tweaks, fidling with user
permission, disabling UAC or unorthodox installs just because of this log
file. I just tested again today on Win 7/ Program Files folder/ UAC enabled
and same problem, it raises an AV error and will not run unless "As
Administrator".

The downside (for Tim i guess is a bit of work, but thats it. The
upside is smooth, trouble free installation of the DBISam Server each and
everytime either by us or by our end users, on current & upcoming Windows
O/S and backward at least to Win XP. Moving the Log file means that the
server does NOT need to "Run As Administrator" which would be much
preferred.

I don't see it as breaking existing installs if done carefully (by Tim of
course . At most, the old log file will just be ignored, its not a
biggy. Or it can also be coded (by Tim again to port the contents of
the old log file over to the new log file at the new path once and for all.
Obviously it needs a bit more thought espiecially with other situations like
server "run as service", network share etc as Raul mentioned but overall I
think it makes things a lot easier.

What do you think Tim ?

regards
Gregory Sebastian

Gregory,

<< I belive the only problem is that the app cannot write to the log file in
the Program Files folder with this executation level. All data, log, config,
ini etc are now meant to me moved elsewhere with current versions of
Windows. Is there any chance of moving the log file to another folder like
ProgramData etc in the future ? >>

I'll see what I can do.  The log file is somewhat inconsequential in terms
of where it is stored, so it's not that big of a deal.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim, much appreciated.


--
Regards
Gregory Sebastian