All records in table disappeared (1 Viewer)

DeanFran

Registered User.
Local time
Yesterday, 20:34
Joined
Jan 10, 2014
Messages
109
I have a split database with about 15 users, each with their own front end. The back end is housed on a NAS on our company LAN. There is also a Datto backup device that backs up the NAS regularly throughout the day. The front end has a login form that pulls from a user table. The login form features a combo box to select the user name, and a password test. On a successful login, the login form doesn't close, it goes invisible. This setup has been live like this for about 2 years with no issues. Monday morning last, the 2nd user (more on this in a minute) of the morning, found the combo box empty and couldn't log in. Upon arrival I was consulted, and I quickly discovered that all the records in the user table were gone, but the table itself seemed to be fine. I went to the Datto backups, and found that the table was populated during all Friday, Saturday, and Sunday backups, but the 8:00 AM Monday backup had the empty table. No one is here over the weekend, something clearly happened Monday morning. I have a very rudimentary bit of code that captures every login and logout of any front end, and found that one user successfully logged in at 7:50 AM, and logged out at 7:51 AM. the next attempt happened somewhere between then and the 8:00 AM backup. I can see the possibility of a corruption of a single record, if a user tried to login to the system during a backup maybe, but its never happened before, and folks are in and out of this system creating and altering records all day long every work day, but not a loss of every record in a given table. Any ideas how this would happen?
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:34
Joined
Feb 19, 2002
Messages
35,925
Any ideas how this would happen?
If there was no successful login after 7:50, then that person might have accidentally or deliberately deleted the users. Do you have a form that allows users to be deleted? You shouldn't. Inactive users should be marked as such and not allowed to log in.

Also, providing a combo to pick a login from is convenient for the users but violates standard security procedures.
 

DeanFran

Registered User.
Local time
Yesterday, 20:34
Joined
Jan 10, 2014
Messages
109
There is no way to delete a user in the front end. If a user has sufficient privileges, ( via a hidden test at login) they have the ability to mark a user as inactive, and an inactive user can no longer login. This user does not have that privilege.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:34
Joined
Feb 19, 2002
Messages
35,925
OK, are you positive that the users cannot get to design view on anything? Are you positive that they cann't get to the BE directly?

This is not something that Access does. Access simply does not lose data.
 

DeanFran

Registered User.
Local time
Yesterday, 20:34
Joined
Jan 10, 2014
Messages
109
The only user that has the nav pane, full ribbon, right click or other menus is me. The BE itself is not secured via password, and its the only thing I can think of. Though to say most of our workforce isn't the most tech savvy is being kind, so someone would have first, been able to locate the BE, next, have Access on their PC, ( not everyone does), and finally be slick enough to not just delete a table, but only delete the records within the table, and select the one table that didn't do much actual damage but simultaneously rendered the system unusable, while also not understanding that we have multiple backups, and that everything would be fixed within minutes of my arrival. Seems far fetched, but who knows? I offered password protecting the BE during the design phase, and was told its not neccessary. Think I'm going to have to request we do it ASAP.
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 17:34
Joined
Oct 29, 2018
Messages
18,791
The only user that has the nav pane, full ribbon, right click or other menus is me. The BE itself is not secured via password, and its the only thing I can think of. Though to say most of our workforce isn't the most tech savvy is being kind, so someone would have first, been able to locate the BE, next, have Access on their PC, ( not everyone does), and finally be slick enough to not just delete a table, but only delete the records within the table, and select the one table that didn't do much actual damage but simultaneously rendered the system unusable, while also not understanding that we have multiple backups, and that everything would be fixed within minutes of my arrival. Seems far fetched, but who knows? I offered password protecting the BE during the design phase, and was told its not neccessary. Think I'm going to have to request we do it ASAP.
I used to recommend against putting a password on the BE as well, because it's very easy to figure out what it is. However, since then, I realized it's, at least, something for non-familiar/non-malicious users to not accidentally get into trouble.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:34
Joined
Feb 19, 2002
Messages
35,925
I was once on a team where we had a programmer who added code to his transaction that prevented the manager from accessing it. In a different situation, it would have been a funny joke. Except that he hated her and was quite vocal about it. He also blocked the assistant manager. Both were black women. Take that where ever you want. He didn't like me much either so I'd go with he just hated women not just black women.
 

DeanFran

Registered User.
Local time
Yesterday, 20:34
Joined
Jan 10, 2014
Messages
109
The plot thickens. A supervisor just came up to me and said, one of my people said something weird happened Monday morning (Oh boy here we go). He was logging in, and while he was typing his password in the password field in the login form, he realized he'd made a mistake, so he pressed Ctrl A then Backspace to clear all the characters ( according to him) and after that the names in the drop down were gone. I tried to recreate what he did, and nothing happened, and I had him recreate what he did, and nothing happened. Clearly he hit some keys other than the ones he remembers. So he magically hit some combo of keys that lead to a keyboard shortcut that somehow deleted all of the records in the user table? Is this even possible from a form on a front end?
*EDIT*
Its the backspace key. He hit the backspace key a couple times and the "You are about to delete XX record(s)" dialogue appears. What the heck?
*EDIT*
 
Last edited:

isladogs

CID VIP
Local time
Today, 01:34
Joined
Jan 14, 2017
Messages
16,076
Well done Sherlock!
With hindsight, its surprising that issue has never occurred before!
Having said that I am unable to replicate the issue on my own login forms.

Whilst I would recommend adding a BE password as a further barrier to potential hackers, that wouldn't have prevented this issue in your case
More importantly how are you going to prevent it happening again?
Whilst a username combo is indeed a security weakness, it does make such events less likely 😉
 

DeanFran

Registered User.
Local time
Yesterday, 20:34
Joined
Jan 10, 2014
Messages
109
So, I think I may have figured it out. The Login form Data Properties had "Allow Deletions" set to Yes. By setting it to No, it appears to prevent this from happening.
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 17:34
Joined
Oct 29, 2018
Messages
18,791
So, I think I may have figured it out. The Login form Data Properties had "Allow Deletions" set to Yes. By setting it to No, it appears to prevent this from happening.
Congratulations! Glad to hear you got it sorted out. Good luck with your project.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:34
Joined
Feb 19, 2002
Messages
35,925
I use bound login forms also BUT neither the userID nor passowrd are bound. Both must be entered and the two are used to find the user's credentials. But, I'm going to run right out and set AllowDeletions to No just in case:)

In your case, I would get rid of the combo. That is too much of a security liability no matter how convenient the users find it.
 

JMongi

Active member
Local time
Yesterday, 20:34
Joined
Jan 6, 2021
Messages
643
I just want to chime in with a giant kudos! There is nothing more patience testing but ultimately more satisfying than tracking down an issue that involves user error combined with a design issue. I applaud your investigative skills and your perseverance! Cheers! :coffee::cool:
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Today, 08:34
Joined
May 7, 2009
Messages
16,116
it's Your fault after all?
nobody ever use a Bound login form?
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:34
Joined
Feb 19, 2002
Messages
35,925
@DeanFran, I would also like to commend your investigative skills. This was a very subtle error and I like your moxie. You stuck to it until you figured it out.

I'm sure I've never run into this because I'm pretty careful about setting the "Allow" properties for special forms like a login.
 

Isaac

Lifelong Learner
Local time
Yesterday, 17:34
Joined
Mar 14, 2017
Messages
6,279
So, I think I may have figured it out. The Login form Data Properties had "Allow Deletions" set to Yes. By setting it to No, it appears to prevent this from happening.
You were using a BOUND form for what should have essentially be a menu? might have mentioned this earlier. And why in the world would you do that
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:34
Joined
Feb 19, 2002
Messages
35,925
@Issac, as I mentioned, I always use a bound form for the login. The userID and Password controls are NOT bound. They are search fields and used to bring up the user information. When the user record is found by using BOTH userID and password in the where clause, the form populates with the user info. The form then opens the menu and hides itself. This lets me reference user information during execution of the app. Sometimes for security auth reasons and sometimes to join to tables to limit data returned, etc.

The reason that @DeanFran had the problem was because he had not set the "Allow" properties correctly. If the form doesn't allow updates/deletes, adds, there is no reason to not use a bound login form.
 

Isaac

Lifelong Learner
Local time
Yesterday, 17:34
Joined
Mar 14, 2017
Messages
6,279
@Issac, as I mentioned, I always use a bound form for the login. The userID and Password controls are NOT bound. They are search fields and used to bring up the user information. When the user record is found by using BOTH userID and password in the where clause, the form populates with the user info. The form then opens the menu and hides itself. This lets me reference user information during execution of the app. Sometimes for security auth reasons and sometimes to join to tables to limit data returned, etc.

The reason that @DeanFran had the problem was because he had not set the "Allow" properties correctly. If the form doesn't allow updates/deletes, adds, there is no reason to not use a bound login form.

Mmmmm yeah interesting, I don't usually mix and match the concept of menu with data on a form, but to each his own.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 20:34
Joined
Feb 19, 2002
Messages
35,925
The loging form is not a menu. It is a login form. It opens the menu when the login is successful. But instead of closing,it hides itself so that certain User information is always available from anywhere in the application without doing additional I/O to get it it.
 

DeanFran

Registered User.
Local time
Yesterday, 20:34
Joined
Jan 10, 2014
Messages
109
I've done some Googling, but I haven't been able to find an explanation of why using a combo box is a greater security risk versus using a textbox for the user name on a login form. Can anyone educate me, or point me to a resource that explains this concept?
 

Users who are viewing this thread

Top Bottom