|Subject:||Re: Interesting Paradox for Windows Permissions issue
|Date:||Tue, 26 Sep 2017 16:15:19 -0400
|From:||"Steven Green" <firstname.lastname@example.org>
so always "install for all users", if given the option?
Myrtle Beach, South Carolina, USA
Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Leslie" wrote in message news:email@example.com...
I thought I would document this for future reference.....
Although we do not actually use Paradox for Windows, one of our Clients does
for another application.
Things have been fine at that site for over 5 years, but they just had a new
machine installed running Windows 10.
This machine is a shared workstation used by two part-time workers in a job
share scenario - they have their own Windows Logins.
Anyway, our application runs perfectly fine without any problems, but since
installation the Paradox application does not work correctly giving all
sorts of random BDE errors. Their IT person was clueless and so they asked
us to have a look.
What we found is sort of interesting, one User account was running Paradox
elevated and the other was not. Our application always runs unelevated (as
As you probably guessed the issue is related to permissions, plus poor
application design. So the first problem is that the Paradox Application's
PRIV location is not private per user but private to the workstation.
Perfectly fine for a one person machine and possibly fine in this case as
well were it not for one of them running it elevated.
Essentially, when the lck files in the PRIV directory get created, they get
the permissions of the current user. If these files do not get deleted when
Paradox exits, and the other User runs Paradox, they get a BDE error because
they do not have the correct permissions to access the lck files. Delete the
lck files manually and the problem goes away.
But then we saw another problem, and this time it was to do with our
application running (unelevated) in parallel with Paradox (elevated). The
same permissions problem occurs with the default net file - the one in
C:\BDE32\NetDir (in our case).
Obviously the solution was to stop running Paradox elevated - we knew it
worked unelevated because the other account did. But we simply could not get
it working under this particular user account. So we created a new user
account and sure enough it ran unelevated there as well. So we transferred
everything over and deleted the original User account.
The only thing that was different about the User account that forced Paradox
elevated was that this was the account that originally installed the Paradox
application. But we had no time to investigate any further because as usual
once it is working the Client does not care once the problem goes away. Time
is money etc etc etc
So as I pondered about this theoretically in another thread somewhere, we
now have real world proof........ Running Paradox for Windows elevated is
not good at all when it is in a shared environment, i.e. other BDE or
Paradox applications or even User accounts.
All effort must be made to ensure that Paradox for Windows runs ***
unelevated *** so that you do not run into weird permissions issues down the
track which can bring other applications screaming to a halt. Or to put it
another way, if you are having to run Paradox For Windows elevated, you have
problem which may or may not bite you later on.