Re: Restrict user licences

Kind of a bizarre requirement.. If your trying to enforce how many people log into a database without the dba's knowing about it, you're barking up the wrong tree. That's an Oracle licensing issue, between the company, and Oracle. If you are attempting to work with an application and license the number of connections, you do it with the app server. What's the problem? Be specific.. Even so, it doesn't really give you the right to restrict database connections, it might even be problematic if some DBA has to debug your app's actions while it's running. When you say.. "there may be a way in Oracle".. that's just a bad idea to begin with. What if the dba has to fire off some tools to analyze performance? That's going to cut into your agreed upon licenses? Since it sounds as if you are trying to restrict the number of users that are using an "APP", then that's where you control it. Not knowing what app your referring to, or how it functions, I don't exactly know how to advise you.

• D

On Fri, 20 Oct 2000 16:33:36 GMT, JD <nongyd_at_my-deja.com> wrote:

>Does anybody know of a standard method of restricting the number of
>concurrent users logging into a bespoke Oracle application. A typical
>scenario would be a company buying a product with 50 user licences, how
>do I then restrict / control the number of users that log onto the
>application.
>
>There may be a way in Oracle, Ive come up with a few, for example
>writing a record to the database, and checking its value every time a
>user logs on, when the user logs off then the value is reduced. This
>seems a sure fire method, but what if theres a power cut, then all
>users will be logged out and the record in the database will still be
>set to 47, 48, 49, 50 .....
>
>Another method may be selecting a count of the records in the v$session
>dba table. However, Im sure a good dba will manage to spoof this table.
>
>Users or the DBA must not have any visability of the solution so they
>can change it.
>
>Does anyone have any standard solution for this issue. All responses
>gladly received.
>
>Regards,
>
>Jonathan.
Received on Fri Oct 20 2000 - 17:18:39 CDT