You need to elaborate on what you want to happen, complete with scenario examples.
It doesn't make sense to get the logged in user name, then attempt to lock that. What happens to the next person trying to log in when someone else has it open? What if the next user logs in and no one else is logged in? In one case, you need to append, in the other, replace, as noted by ssanfu. And did you consider what needs to happen if a user forces an abnormal shutdown (as in using Task Manager to kill Access), in which case they probably remain recorded as being logged in?
Also, Missinglinq is correct on the oddities of the DLast (and First, Last, DFirst) functions but in some cases it would work as one would expect. AFAIK, the record returned is not really random, it is supposed to be (when using Last or DLast) the last record entered into the table. That certainly would appear to be random when looking at a table recordset, especially if it is not sorted.
https://support.microsoft.com/en-us/kb/208190
The First(), Last(), DFirst(), and DLast() functions ignore sort orders, indexes, and primary keys. These functions return the first or last undeleted record based on the order in which the records were entered into the table, not the first or last record in a specified sort order.
That last record entered is not always going to appear at the end of the table rows.
So if you want to know
- who is logged in
- who is logged in and who logged in last
- only who logged in last
these require different approaches.
A straightforward answer to getting the last value* from a table field is to use a sorted query and use the Top 1 predicate.
*not to be confused with the max value
I'm curious; is this db split?
Last edited by Micron; 01-05-2017 at 08:08 PM.
Reason: clarification
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.