All records in table disappeared

[JMongi]

There are other considerations, but from a strictly security standpoint (i.e. making it difficult for unauthorized individuals to login) providing a list of correct usernames is providing one half of the login "key" already (albeit the easy half). Requiring a user to ENTER his username AND password THEN checking that against the approved user list is more secure than providing a list of already approved users.

Do you regularly run into combo boxes when entering your username in Windows? Websites? Phone Apps?

From a strictly UI standpoint, a combo becomes unwieldy to use above a certain list threshold.

Drop-Down Usability - Drop-Down UX – Baymard Institute

Drop-downs can be a risky UI choice. This article reveals principles to help you decide when drop-downs work — and when they don’t.

baymard.com

 

[JMongi]

Consider a different security setup: card keys for building entry.

Now to make this applicable our card key entry system would require a card swipe and then the entry of user's pin number.
To summarize: swipe the user's unique card, enter the user's unique pin number.
To gain unauthorized entry to the building would require a card and pin combination.

Which is more secure? Everyone having their key card on their person or storing all the key cards at the front door in a box? The box would be more convenient for those who have a tendency to forget their key card at home, but does that make building access more or less secure?

Providing a combo box of authorized users is like providing the box of key cards at the front door.

 

[DeanFran]

Good points I hadn't considered. Thank you for taking the time to reply. And we've already violated one of the usability rules, as we currently have 12 active users.

 

[gemma-the-husky]

I would think the good thing is that you found the cause, and nobody had deliberately trashed the data. Luckily it only happened to a relatively innocuous data set. Could the same process destroy volatile data by accident?

 

[DeanFran]

I would think the good thing is that you found the cause, and nobody had deliberately trashed the data. Luckily it only happened to a relatively innocuous data set. Could the same process destroy volatile data by accident?

I had that thought, so I went through all of the other user forms, and the particular combination that allowed this to happen doesn't exist anywhere else.

 

[isladogs]

A combo will give a list of valid user names which could help someone break into the app as another user.
OOPS - I hadn't seen the replies on this page when I replied

 

[Pat Hartman]

What is the point of a login? Is it to secure the database from people who shouldn't have access or is to simply know who has logged in? If your intention is to keep out people who shouldn't have access, then using a combo, gives those "outsiders" half of the credentials they need to log in.

Access databases are not particularly secure to begin with especially when the BE is Jet/ACE rather than a server based RDBMS so using a combo isn't terrible but I would NOT recommend it if my instructions were to try to keep out people who don't belong..

 

[DeanFran]

In our case, its less about keeping unauthorized people out, and more about preventing unauthorized people from adding new, and more importantly, altering existing data accidentally or on purpose.

 

[Pat Hartman]

Wow, three of us missed earlier replies. That is really odd. At least we all agreed on why the combo made logging in less secure

 

[Isaac]

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.

When I said 'menu', I probably should have said 'non-data' form, which is what I consider to be any form not dealing with the actual data that the db is meant to manage.

Pretty much (with maybe a rare exception?) - NO form in my db's, which isn't dealing with core data, is bound. Period. That's more what I meant since we can quibble about the meaning of 'menu'.

 

[Isaac]

I would think the good thing is that you found the cause, and nobody had deliberately trashed the data. Luckily it only happened to a relatively innocuous data set. Could the same process destroy volatile data by accident?

Exactly along similar lines as I was thinking when I said I don't mix and match the concepts of menus vs. data.
You're lucky the only thing that disappeared was config type of info and not core data.

 

[Babycat]

I silently checked my login-form. Somehow, it bounds to tbl_User accidentally, it could be my intention in the past. But textboxes dont bound to any field. Therefore, I dont have "delete all" record issue. But for safety, I have removed bounded table from the form.

 

[The_Doc_Man]

Since we had a formal domain with the U.S. Navy, and the group policy downloads that occurred at each user's laptop's startup locked down the user's ability to diddle with certain symbolic objects, we could trust the domain names, computer names, and usernames AND could trust that the user had logged in successfully. I'm not at all saying you should do this, but rather offering the idea that if you have a formal and relatively trustworthy domain setup, the user's domain login name is another tool in the tool box that you could use to identify users.