|Subject:||Re: Interesting Paradox for Windows Permissions issue
|Date:||Wed, 27 Sep 2017 16:13:13 -0400
|From:||"Steven Green" <email@example.com>
if "elevated" doesn't mean "admin", I'm confused.. that link doesn't work
Myrtle Beach, South Carolina, USA
Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Mark Bannister" wrote in message
Leslie's suggestion to install paradox outside of the programs seems to
be a better option (and for all users) .
That fixed elevated permission issues for me.
On 9/26/2017 3:15 PM, Steven Green wrote:
> so always "install for all users", if given the option?
> Steven Green
> Myrtle Beach, South Carolina, USA
> Collectibles and Memorabilia
> Vintage Lego Sets and Parts
> - and Paradox support, too
> "Leslie" wrote in message news:firstname.lastname@example.org...
> Hi All,
> I thought I would document this for future reference.....
> Although we do not actually use Paradox for Windows, one of our Clients
> for another application.
> Things have been fine at that site for over 5 years, but they just had a
> machine installed running Windows 10.
> This machine is a shared workstation used by two part-time workers in a
> share scenario - they have their own Windows Logins.
> Anyway, our application runs perfectly fine without any problems, but
> 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
> it should).
> 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
> the permissions of the current user. If these files do not get deleted
> Paradox exits, and the other User runs Paradox, they get a BDE error
> they do not have the correct permissions to access the lck files. Delete
> 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
> 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
> elevated was that this was the account that originally installed the
> application. But we had no time to investigate any further because as
> once it is working the Client does not care once the problem goes away.
> 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
> 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
> problem which may or may not bite you later on.