Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Modules / DAO / VBA / January 2006

Tip: Looking for answers? Try searching our database.

Licensing Access apps

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Brian - 05 Jan 2006 21:00 GMT
Any clever ideas on licensing/enforcing concurrent users for Access apps I
distribute? How about this:

Have a table in the BE that has a LicenseID field (or, better yet, embed the
license in a custom DB property)
Have the number of users for this license embedded in the license and
extractable via VBA.
Have a "logged on" field in my users table (not using Access security, but a
Users table with an encryption routine for the password field).
Update this field to True each time a user logs on.
Update this field to False each time a user logs off.
Deny access if the user is already logged on.
Deny access if the number of users logged on equals or exceeds the license
count.
Provide an administrative tool to "unlock" users.

Pitfalls? Better ideas?
Alex Dybenko - 06 Jan 2006 10:35 GMT
Hi,
difficult to say without knowing your application. in general looks ok, but
be aware that user can leave application without logging off, so you have to
reset "logged on" field in this case somehow

Signature

Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com

> Any clever ideas on licensing/enforcing concurrent users for Access apps I
> distribute? How about this:
[quoted text clipped - 15 lines]
>
> Pitfalls? Better ideas?
Brian - 06 Jan 2006 16:25 GMT
The code to log off would be contained within the code on my Quit button. The
only times this could be bypassed is when a user closed Access using the
Close button in the Control Box (something a user will try only once!) or an
unexpected system shutdown or network interruption.

Since the only part that is running is the front end (obviously not a
client-server application), it seems to me that if a user lost his
connection, the next time the issue could be resolve is when he logs on
again. However, I cannot simply assume that a user's second logon is due to a
lost connection; otherwise, what is there to prevent many users using the
same ID? It seems like it would be best to just have a field in the users
table that can be reset by users having access to the form that contains the
field.

That's the administrative "unlock" field I was considering; a manual reset
of the LoggedOn field in the users table via a limited-access form.

> Hi,
> difficult to say without knowing your application. in general looks ok, but
[quoted text clipped - 20 lines]
> >
> > Pitfalls? Better ideas?
Alex Dybenko - 07 Jan 2006 10:09 GMT
> The code to log off would be contained within the code on my Quit button.
> The
> only times this could be bypassed is when a user closed Access using the
> Close button in the Control Box (something a user will try only once!) or
> an
> unexpected system shutdown or network interruption.

you can also handle "user closed Access using the Close button in the
Control Box" if you use a hidden form (or some switchboard form)unload event
to run log off code

Signature

Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com

Brian - 07 Jan 2006 16:31 GMT
I hadn't thought of using the unload event. Thanks.

> > The code to log off would be contained within the code on my Quit button.
> > The
[quoted text clipped - 6 lines]
> Control Box" if you use a hidden form (or some switchboard form)unload event
> to run log off code
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.