A prospective customer says that my application works fine with one user, but "freezes" when another user runs the application.

Would I be right in thinking that this is some sort of Windows permissions issue with the lock file?

The application is client/server only.  It is used by thousands of other customers that don't have this problem.

= Steve

Steve


Obviously, without the application in front of me I can't make much more than a guess.

I am assuming that all the users do have permissions for the tables, if not I'd expect a Windows error message.

My guess is that your application isn't handling locks correctly.  If, when a user starts your application something is locked (might even be in ElevateDB's configuration database eg Users) and then the second one starts, tries to lock the same thing and woops.

Roy Lambert

On 1/24/2022 7:07 PM, Steve Gill wrote:
> A prospective customer says that my application works fine with one user, but "freezes" when another user runs the application.
>
> Would I be right in thinking that this is some sort of Windows permissions issue with the lock file?
>
> The application is client/server only.  It is used by thousands of other customers that don't have this problem.

Not enough info - if it's a true C/S setup then users should be same
from EDBServer perspective - i.e. server side permissions and locks are
for EDBServer not user based.

Like Roy said start checking what your app is doing exactly - either
locks or maybe trying to access something that locks (like network share
or such) or app permissions on device (do you write files or such
locally) - these are total guesses

Raul

Hi Roy,

<< Obviously, without the application in front of me I can't make much more than a guess. >>

Yeah, bit hard to give you the whole thing.


<< I am assuming that all the users do have permissions for the tables, if not I'd expect a Windows error message. >>

It's pure client/server so that isn't necessary.


<< My guess is that your application isn't handling locks correctly.  If, when a user starts your application something is locked (might even be in ElevateDB's configuration database eg Users) and then the second one starts, tries to lock the same thing and woops. >>

It's not doing anything special.  Nothing should be locked.  I use stored procedures exclusively and they all execute extremely fast.  There is only one site out of thousands that are experiencing this issue.

I'm remote connecting to their computers in a couple of days so hopefully I'll find what the cause is.

Thanks anyway.

= Steve

Hi Raul.

<< Not enough info - if it's a true C/S setup then users should be same
from EDBServer perspective - i.e. server side permissions and locks are
for EDBServer not user based. >>

I know but it's a bit hard to provide you with any more info than that.  Yes, as I said it's Client/Server only.  I've never used local mode for anything.

<< Like Roy said start checking what your app is doing exactly - either
locks or maybe trying to access something that locks (like network share
or such) or app permissions on device (do you write files or such
locally) - these are total guesses >>

It's ok.  Just thought I'd pose the question in case someone had come across something like this before.  I'm not expecting anyone to diagnose the issue if they've never seen it happen.

I'm remote connecting to their computers in a couple of days so hopefully I'll find what the cause is.

Thanks anyway.

= Steve

Steve

><< Obviously, without the application in front of me I can't make much more than a guess. >>
>
>Yeah, bit hard to give you the whole thing.
<giggle>


><< I am assuming that all the users do have permissions for the tables, if not I'd expect a Windows error message. >>
>
>It's pure client/server so that isn't necessary.

Its still necessary even if there is only one user However, this was mainly in response to your thought it could be permissions on the locks file

><< My guess is that your application isn't handling locks correctly. If, when a user starts your application something is locked (might even be in ElevateDB's configuration database eg Users) and then the second one starts, tries to lock the same thing and woops. >>
>
>It's not doing anything special. Nothing should be locked. I use stored procedures exclusively and they all execute extremely fast. There is only one site out of thousands that are experiencing this issue.

You don't need to do anything special, just something that causes a race

A few random thoughts / questions:

Do they log in, if so do they use ElevateDB or something of your own?

Do they have Exclusive mode set (even for one table)?

Is anything done when they start the application that causes alteration of the configuration database? Generally that means a lock being set

Is it local users or remote users that are having the freeze?

Can anti-virus be screwing them?

Are they exceeding the maximum number of connections?


GOOD LUCK with your remote login - I don't envy you.

Roy

Thanks for all the suggestions Raul and Roy.

It turns out that the information they gave me wasn't entirely accurate.  What was happening was that there was a modal dialog (a standard one) that was hidden.  They all have 3 screens (lucky them) and the dialog was appearing on a different screen to the application, hidden behind something else.

Fortunately they have an option under the settings to turn that dialog off.  That solved the problem for them.  However, I need to find out why the dialog is behaving the way it is.  That's another story.

= Steve

Steve


Z order / screen is a bugger on WIndows - you have my best wishes in your investigations. I do have a faint memory of there being a way to tell things which monitor to use, but I also faintly remember some forms and dialogs (especially Windows native dialogs) doing their own thing


Roy Lambert

<< Z order / screen is a bugger on WIndows - you have my best wishes in your investigations. I do have a faint memory of there being a way to tell things which monitor to use, but I also faintly remember some forms and dialogs (especially Windows native dialogs) doing their own thing  >>

Thanks Roy.