ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Pervasive SQL >> >> multiple logins in user screen
http://www.istechforum.com/YaBB.pl?num=1163530193

Message started by cathyh on 11/14/06 at 10:49:53

Title: multiple logins in user screen
Post by cathyh on 11/14/06 at 10:49:53

I don't know if this is happening since the latest update, but today I looked in the Pervasive active user log on the server and everyone logged in is in this screen at least twice. One login is the islog user screen, and one is in WBTRVMEMO.B. If they are in programs they are listed two more times, one with the active program files, and another WBTRVMEMO.B.
I am concerned that these multiple logins will affect our user count. Yes, or no?

Title: Re: multiple logins in user screen
Post by NovaZyg on 11/14/06 at 11:04:14

Cathy,

The wbtrvmemo is the new notes file system, and yes I see the same thing. I do not believe it takes up any additional seats, but if it does let me know ASAP. I think if it did I would have heard about it by now though.

Title: Re: multiple logins in user screen
Post by GasGiant on 11/14/06 at 12:04:50

It has added about 20 handles for us, going waaay beyond our licenses, but without any complaints from Pervasive.

Title: Re: multiple logins in user screen
Post by kkmfg on 11/14/06 at 12:29:10

Same here, 5 user license but something like 10 or more users showing up in the monitor. It doesn't complain.

My guess is that one user is counted as one instance of a program running on one machine. So two copies of EVO counts as two users but three connections from within the same Evo instance count as one.

On an unrelated note, it sucks that pervasive is per user licensed... How about a switch to Firebird or PostgreSQL some time in the future? ;-) <ducks>

Title: Re: multiple logins in user screen
Post by Kelloggs on 11/14/06 at 13:56:59

MySQL or PostgreSQL

That would be nice.

:P

Kelloggs

kkmfg wrote:

Title: Re: multiple logins in user screen
Post by stew on 04/04/07 at 12:53:49

I am seeing the same thing. Found it when trying to find out why a user was locked out of AP. I found that even though the user had logged completely out of EVO the pervasive monitor had 6 open connections for this user.

Anyone having this same issue on EVO? I just updated from DBA to EVO and just noticed the problem.

Title: Re: multiple logins in user screen
Post by NovaZyg on 04/04/07 at 13:31:39

It is not a License issue, it is a Pervasive and TAS 7 (the programming language that Evo/DBA is written in) Multi Thread issue. The user may have multi sessions open under pervasive monitor, but it is only taking up one seat of your pervasive license.

Title: Re: multiple logins in user screen
Post by BtrieveBill on 04/18/07 at 14:50:45

What you see in the Pervasive Monitor is each SESSION, not each LICENSE. A session is established by the application to talk to the database -- kind of like having its own phone line direct to the server. The Pervasive engine tracks licenses, on the other hand, by "unique network address" accessing the engine. Therefore, if you run a database application from 6 workstations and the server, you will use up 7 licenses. If you do not run anything on the server itself, this will only be 6 licenses.

There is one caveat to this that usually messes people up:

If you are right near your user count limit, and a workstation gets "abnormally terminated", whereby it is unable to close the application properly, the session (and thus license) will remain open on the server. This can prevent you from signing in from a different computer right away, but would have no impact on signing in from the SAME machine.

These orphaned connections will get cleaned up in time by the TCP watchdog process, which will send an "are you alive?" watchdog packet to each workstation session when it has not received a request for the last 2 hours. If the workstation doesn't respond, the session will be cleaned up properly. If the session DOES respond (which can happen if you End-Task the application, but don't reboot the PC to reset the database client), then the session can stay indefinitely. [Yet another reason why you should reboot if you ever crash your app.]

You can alter this time limit easily be enabling the Pervasive Auto-ReConnect (PARC) feature of the database, which will reduce the clean-up time to 3 minutes (by default). Of course, this also decreases the watchdog timer and increases the overhead, so a busy system may see a performance penalty if you enable PARC.