Login question: need to check if another user is logged in DB!

[schredder]

Hi all

Have set up a simple login procedure for my database. Created a table where username and password is stored. When a user logs in the database my code checks if the entered password matches the one in the table. That's it.
For updating reasons i only want to have one user logged in at once (only 3 users network). Can anybody provide me with a direction of how to set up a field which shows in the login form, whether a user is currently logged in?!
Thanks for any help.
Chris

 

[mp9]

The issue of capturing whether a user is logged in under this arrangement is trivial (add a yes/no field to your user table and when the user logs in set it to yes at the same time you verify the password, using either VBA and SQL or a straightforward query).

However, it's more difficult to set this back to "No" when the user logs out because of the variety of ways the user can close Access (going through menus/toolbars, just clicking the X in the top-right corner, etc). You could think about having some code on the unload event of a form that fires when the user exits the database to set the yes/no field back to "No" - a switchboard form, if you have one, would be ideal, otherwise consider a hidden form.

As an aside, this security really isn't very secure. The database startup can be bypassed by holding down the Shift key, thereby completely circumventing your password lookup. Okay, this can be disabled too, using AllowBypassKey (which you can get a fuller explanation of in Access help) but to be honest I'd recommend implementing Access' own user-level security.

Hope this helps.

http://www22.brinkster.com/accessory/

 

[schredder]

hey mp9

thnx lot for ur feedback. think i'll give it a try.
chris

 

[MichaelRed]

Then, consider how you will deal w/ a simple 'crash' of either the "server" or the desktop. If anyone is "logged in" the db is as effectively "locked" as your programming of the log in / log out procedures. If you are "good" it is "Gone" (good and gone?).

MUCH better to invest in the learning of Ms. A. Security. It is almost certailnly better htan you will develop AND will automatically detect users logging off through 'accidental' events.



MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[TLady]

I might be off a lot,
but how about right click on .ldb file?

 

[MichaelRed]

TLady re What? The ".ldb" is a temporary device created and (sometimes) destroyed by Ms. A. it generally is NOT a reliable indicator of much. It does not necessarily delete a user simply because they close the db connection (entries are "reuseable&quot. It does not always disappear (get deleted) even when the last user exits the db in a "normal" manner. It almost never gets deleted when the last user is disconnected via "accident", It is NEVER deleted when the db is exited through a "CRASH", regardless of the source / location of the "CRASH". Thus, AFAIK, it is of quite limited use to the casual user / programmer. Ms. A. does seem to have a better 'handle' on managing the thing, but I believe they are using varions API calls to determine the connection count to the associated db to decide that it is appropiate to delete the ",ldb" and internally only use it to determine which (if any) record / blocks are locked by each user.



MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[JeremyNYC]

Michael,

I certainly agree with you on this. I just did a bit of thinking about how one would actually do this. My notion is this: it would work much like the code many people use to log users out of a database--when it's time to check who else is in the database (opening up the problem space just a tad so we can get more info back), update a field in the database that gets checked in the Timer event of a form that is always open. If that field (HeadCount) is true when the Timer event follows, make sure there's one and only one record in a table that holds the userName for the current user. After one cycle of this, you'll have a relatively accurate picture of who's in the database.

I've given it no more thought that what it took to write that paragraph, but it seems like it could be a fairly useful feature, in some situtations.

What holes do you see in it?

Jeremy

==
Jeremy Wallace
AlphaBet City Dataworks

http://www.ABCDataworks.com

Affordable Development, Professionally Done

Please post in the appropriate forum with a descriptive subject; code and SQL, if referenced; and expected results. See thread181-473997 for more pointers.

 

[MichaelRed]

To a point, it (seems to me) that it always return the chicken vs. egg discussion.

If you have some process which permits the opening of the db enough to "check" who is logged in, then it needs to be a startup object (form or autoexec macro). These can generally be bypassed, so the next step is to disable the bypassing of the startup object. Once arriving at this (critical) juncture, it is necessary to 'examine' the status of others also being in the db, and (programatically) deciding what to do re the existance of someone (anyone) already loggged in. Assuming there is no prior login, the process simply proceds to ennter the current user as the loged in individual. the alternative is that there is already some one logged in, in which instancethe trail of trouble starts. Whwt to do? If the 'new' supplicant is simply booted, there appears to be no way to re-open the db after the first crash / lock-out. If an alternative is presented, how does REAllY differ from a 'gentler and kinder' approach of simply having a pop-up inform the new supplicant of the prior occcupant and (again with deference and courtsey?) ASKING them to "butt out" as it were?

While there are perhape a myriad or more variations on the theme, I do not see any path through the maze which does not produce the conundrum.

Perhaps, the more basic issue or question(s) should be addressed.

First, Ms. A. is designed and intended as a multiuser process, so what the $^%^$#%^ is going on that cannot be accomodated? An expliniation (in some detail) would be necessary to convince ME that it should be restricted to the single user. I cannot realstically see the need or use of guilding the lilly partiicularly in a public and pro-bono setting. I participate (in Tek-tips) to improve my skills in some USEFUL aspects.

Second, what is wrong with the use of Ms. A. Security? With some reasonable effort, the app can be protected from both un-authourized use and provide a mechanisim to reasonably devine the actual number of users involved, including their Group member ship (roles). This requires (virtually?) no unique programming and presents no hurdle which cannot be easily discussed and explained. So this part is essientially saying that schredder even with the aid, comfort and advice available publically is not likely to improve on the (securrity) weel - so what is the point of the re-invention?





MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[cmmrfrds]

To find current logged in users Microsoft has something called userroster schema. Look up user roster on the microsoft site. Here is a function that uses it - basic but could be expanded.


Function ReturnUsersLoggedIN()

Const dbSecUserRosterGuid = "{947bb102-5d43-11d1-bdbf-00c04fb92675}"
Dim rs As ADODB.Recordset
Dim con As ADODB.Connection

Set con = CurrentProject.Connection
Set rs = con.OpenSchema(adSchemaProviderSpecific, , dbSecUserRosterGuid)
If (rs.EOF = True And rs.BOF = True) Then
Exit Function
End If
Dim cnt As Integer, indx As Integer
indx = 0
cnt = 500
rs.MoveFirst
For indx = 0 To cnt
Debug.Print rs(0).Name; " = "; rs(0).Value
Debug.Print rs(1).Name; " = "; rs(1).Value
Debug.Print rs(2).Name; " = "; rs(2).Value
''Debug.Print rs(3).Name; " = "; rs(3).Value
rs.MoveNext
If (rs.EOF = True Or rs.BOF = True) Then
Exit For
End If
Next
End Function

 

[MichaelRed]

Interesting.

on an unsecured db, it retutrns the Computer Name, the db default login ("Admin&quot and "Connected". Perhaps it can be modified to return the users of a db / app other than "CurrentProject". I remain convinced that the chicken-egg issue controls the ultimate use.

I did look back into the command line options and found (re-discovered) the /Exec switch. It SEEMS to me that this handy little item (or it's startup option twin cousin) would be reasonably effective in keeping honest people honest w/o the necessioty of re-inventing the security wheel.

MichaelRed
m.red@att.net

Searching for employment in all the wrong places