On Saturday 02 February 2002 02:13 pm, Leyne, Sean wrote:

> Brad,
>
> > I know I could write an entry to a table when users connect
> > and then remove
> > it when they disconnect but this is so fraught with perils I
> > hate to do it!
>
> This would be the 'best' approach -- you could make the process more
> intelligent by updating the usage data on a timed basis (in a thread),
> such that entries which have not been updated (last updated 16 minutes
> ago but the update interval is 15 minutes) can be deleted from the list.
> That way the user/login count is accurate.

Ok I'll consider this.

> Remember that IB really only counts/restricts connections which is not
> the same thing as users, since a number of application use many-many
> connections.

Well actually want I really want to do is count connections. The way we
license our software is by concurrent user which is counted as distinct ip
addresses connecting. So if you buy a two concurrent user license, you can
connect as many times as you want from two computers on the network.
Actually an added issue is the local connections are always allowed so you
can always get in and do sysadmin work.

I was able to get this counting on Linux Firebird by writing my own server to
replace inetd/xinetd. The other database we support (Sybase ASA) also uses
concurrent users for licenses. So the only remaining problem is the super
server version on Windows where I can't limit it like I have everywhere else!

> Additionally, depending on the design of your application, an
> application user might not match up to a DB user (for our applications,
> user login using a unique userid but the application connects to the
> database using common/hidden user/password). Also, in the case of
> multi-tier application the application server usually pool connections
> which have been openned using a common username/password. You want to
> count application users/logins, not database connections.

These are the reasons we license by concurrent user and want to count
distinct database connections and not users!

--
Brad Pepers
brad@...