[AccessD] Restrict # of User Logins to Access Part 2

Jim Dettman jimdettman at earthlink.net
Wed Aug 20 09:06:43 CDT 2003


Don,

<<Is it a true staement that the LDB file will be 1k when abnormally
terminated?>>

  It could be 1k sure, but is it always 1k? No.  An ldb file can be anywhere
from 64 bytes up to 16,320 bytes (15.9k) depending on the number of users
that are logged in at the time, which user caused the corruption, and how
abnormal the termination is (did everyone get the boot at once or did other
users have a chance to log out?)

Jim Dettman
President,
Online Computer Services of WNY, Inc.
(315) 699-3443
jimdettman at earthlink.net

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Don Elliker
Sent: Wednesday, August 20, 2003 9:41 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2


Is it a true staement that the LDB file will be 1k when abnormally
terminated?
_d


"Things are only free to the extent that you don't pay for them".-Don
Elliker





>From: "Jim Dettman" <jimdettman at earthlink.net>
>Reply-To: Access Developers discussion and problem
>solving<accessd at databaseadvisors.com>
>To: "Access Developers discussion and problem
>solving"<accessd at databaseadvisors.com>
>Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2
>Date: Wed, 20 Aug 2003 09:26:52 -0400
>
>BTW, you misspoke on something.  The locks are never placed against the MDB
>file.  All locks are written against the LDB file.  I know you know this
>because of the utility you wrote<g>.
>
>  Also, I have never seen a LDB file hang around because two people leave
>at
>the same time. I'm not saying it can't happen, but I've never seen it as a
>normal matter of course.
>
>   Typically, LDB's will remain if a user terminates abnormally and the
>user
>lock is left hanging or if they don't have delete rights for the directory
>where the LDB resides.
>
>Jim Dettman
>President,
>Online Computer Services of WNY, Inc.
>(315) 699-3443
>jimdettman at earthlink.net
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Drew Wutka
>Sent: Tuesday, August 19, 2003 5:51 PM
>To: 'Access Developers discussion and problem solving'
>Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2
>
>
>No, you are talking LDB file, NOT the user lock.  The user lock is actually
>the one lock made directly on the .mdb itself.  I have never seen that get
>stuck.  I HAVE seen .ldb files hang around, but the user locks are cleared,
>and if you open and close the database, the .ldb usually disappears.  The
>.ldb hangs around because two users leave at the same time, and they both
>think the other is still there, so it stays (that's just one of the
>reasons....).  But whether the .ldb stays or not, is independant of the
>user
>locks within the .mdb itself.
>
>The sample database I provided a link for shows both the .ldb information
>(which only shows what users have 'been on',not whether they are on or
>not),
>and the .mdb user lock bits.
>
>Drew
>
>-----Original Message-----
>From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
>Sent: Tuesday, August 19, 2003 4:38 PM
>To: Access Developers discussion and problem solving
>Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2
>
>
>How about Windows Explorer?  If you can see the ldb file when no one is
>in it, I'd say it was stuck.
>
>Charlotte Foust
>
>-----Original Message-----
>From: Drew Wutka [mailto:DWUTKA at marlow.com]
>Sent: Tuesday, August 19, 2003 1:14 PM
>To: 'Access Developers discussion and problem solving'
>Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2
>
>
>Never had an issue local, or with network.  What are you using to 'view'
>the status of a user?
>
>Drew
>
>-----Original Message-----
>From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
>Sent: Tuesday, August 19, 2003 3:04 PM
>To: Access Developers discussion and problem solving
>Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2
>
>
>I've seen them stick on a local basis too.  But it is especially an
>issue in a network setting.
>
>Charlotte Foust
>
>-----Original Message-----
>From: Drew Wutka [mailto:DWUTKA at marlow.com]
>Sent: Tuesday, August 19, 2003 11:56 AM
>To: 'Access Developers discussion and problem solving'
>Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2
>
>
>I've never had user locks stick!  Sounds more like a network issue.
>
>Drew
>
>-----Original Message-----
>From: Francisco H Tapia [mailto:my.lists at verizon.net]
>Sent: Tuesday, August 19, 2003 1:36 PM
>To: Access Developers discussion and problem solving
>Subject: Re: [AccessD] Restrict # of User Logins to Access Part 2
>
>
>Maybe in the deluded M$ view, but in real life, user locks stick all the
>time.  Perhaps a better scenario would be to have a timed formed poll a
>file and update it based on who is still logged on.
>
>-Francisco
>http://rcm.netfirms.com
>
>On Monday, August 18, 2003 1:41 PM [GMT-8],
>Drew Wutka <DWUTKA at marlow.com> wrote:
>
>: No. And almost.  You have to have a bad crash to make the user lock
>: stick. In which case, making that one function work is not going to
>: be the primary concern.
>:
>: Drew
>:
>: -----Original Message-----
>: From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
>: Sent: Monday, August 18, 2003 3:04 PM
>: To: Access Developers discussion and problem solving
>: Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2
>:
>:
>: But isn't there a delay in clearing out locks in the ldb file?  If
>: they shut down on one machine and went to another, is there any
>: guarantee
>: that the lock would be gone?
>:
>: Charlotte Foust
>:
>: -----Original Message-----
>: From: Drew Wutka [mailto:DWUTKA at marlow.com]
>: Sent: Monday, August 18, 2003 12:02 PM
>: To: 'Access Developers discussion and problem solving'
>: Subject: RE: [AccessD] Restrict # of User Logins to Access Part 2
>:
>:
>: My solution to use the .ldb should work fine with the BE .mdb.
>:
>: Drew
>:
>: -----Original Message-----
>: From: Greg S [mailto:weeden1949 at hotmail.com]
>: Sent: Monday, August 18, 2003 2:45 PM
>: To: Access Developers discussion and problem solving
>: Subject: [AccessD] Restrict # of User Logins to Access Part 2
>:
>:
>: Well, in the midst of explaining myself more clearly (seems I have to
>: do that a lot at my age...), I discovered I may have left out a VERY
>: vital detail.  Each user's application resides on his or her local
>: machine, so the only way to see who's logged in will have to be
>: through the secured mdw file.  In other words, I won't be able to
>: have a common table in the Front End to use for comparisons or times.
>: Everything will have to
>: reside in the BE, where there are no queries or forms, just tables.
>:
>: This may or may not make any difference, but I thought you all should
>: know that.
>:
>: Greg
>:
>:
>: ----- Original Message -----
>: From: "Greg S" <weeden1949 at hotmail.com>
>: To: "Access Developers discussion and problem solving"
>: <accessd at databaseadvisors.com>
>: Sent: Monday, August 18, 2003 2:18 PM
>: Subject: Re: [AccessD] Restrict # of User Logins to Access
>:
>:
>: Charles:
>:
>: Well, phooey.  Once again I made myself NOT clear...like mud.  Sorry.
>:
>: What I meant was the same username (Phred, for example...), can't be
>: logged into the db more than once, at the same time.  Regardless of
>: what terminal or workstation they are on.  If Phred is in the DB once,
>: another user (or the same one at a different computer) can't login
>: with Phred again.
>:
>: And, now that you mentioned that, she also did say she wanted to
>: restrict their times in the database.  The database is online within
>: their offices 24/7, except during backups, but she wants to restrict
>: them to using it from, say, for example, Monday through Friday,
>: 0900-1500, only.  I haven't thought about that too much yet, but it
>: might not be too hard to implement.
>:
>: Greg
>:
>:
>: ----- Original Message -----
>: From: "Wortz, Charles" <CWortz at tea.state.tx.us>
>: To: "Access Developers discussion and problem solving"
>: <accessd at databaseadvisors.com>
>: Sent: Monday, August 18, 2003 1:20 PM
>: Subject: RE: [AccessD] Restrict # of User Logins to Access
>:
>:
>: Greg,
>:
>: Once in a lifetime?  Or once in a day?  Or once in an hour?
>:
>: If it is the first, then you have a separate table with flags you set
>: for each user.  Once the flag is set, they are locked out forever.
>: For the latter options, you add a date/time field to record when they
>: accessed and then compare the time of their next attempt to access to
>: see if the proper length of time has expired.
>:
>: Charles Wortz
>: Software Development Division
>: Texas Education Agency
>: 1701 N. Congress Ave
>: Austin, TX 78701-1494
>: 512-463-9493
>: CWortz at tea.state.tx.us
>:
>:
>:
>: -----Original Message-----
>: From: Greg S [mailto:weeden1949 at hotmail.com]
>: Sent: Monday 2003 Aug 18 10:53
>: To: Access Developers discussion and problem solving
>: Subject: [AccessD] Restrict # of User Logins to Access
>:
>: Hello everyone!
>:
>: I got a request from a client that I'm not sure how to handle...and I
>: hedged enough so as NOT to commit to anything until I have it figured
>: out.
>:
>: Their current system is in Access 97, using full Access's security.
>: It's setup fairly well, with users being members of groups and rights
>: assigned to the groups.  Now she's thrown me a curve.  She wants to
>: allow users from another department to login to her system, but ONLY
>: ONCE (her reasoning is sound - she does not want users from another
>: group tying up all her resouces and licenses with multiple logins).
>: That is, that username can only login to the Application once...one
>: concurrent usage.
>:
>: Windows security would do this easily, but Access 97's doesn't have a
>: place to select the number of logins per user.
>:
>: Any suggestions on how to do this?  I've just had a second temporary
>: crown put in this morning (since last week), it's fairly early, I've
>: NOT had sufficient coffee, and I'm a bit fuzzy (fuzzier??) around the
>: edges this morning and it's not readily apparent to me on how to do
>: this.
>:
>: Thanks!!
>:
>: Greg Smith
>: weeden1949 at hotmail.com _______________________________________________
>
>
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>
>
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com

_________________________________________________________________
<b>Get MSN 8</b> and enjoy automatic e-mail virus protection.
http://join.msn.com/?page=features/virus

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list