Next record button has started creating new records

[Pat Hartman]

I'm just saying this is one of my few complaints.

It isn't an issue as long as you understand how to always stop it if you need to. Access is designed to always save because it is designed to be user friendly and in general, users are happier if their data isn't accidentally lost.

Concur with @Isaac. I've worked around it, but just about any other application let's you make changes and then when you want to exit asks "Do you want to Save?" (which is annoying if you just saved and haven't made additional changes.)

There are far better ways to control the save than to always prompt. When you always prompt, all you are doing is training the user to ignore your messages and always press OK. And bad data still gets saved when you don't use the correct event. I once removed over 5,000 lines of validation code from a single Access app because the developer didn't understand how forms worked and put validation code into every event he could think of, multiple times, but couldn't stop Access from saving the bad data. Why? NONE of the code was in the correct event.

Unless you add some kind of Before_Update verification, Access saves and then hopes you have a backup of the old version if you didn't intend to make the change.

The developer is ALWAYS in control but only if he knows how. There are far worse things about Access than its desire to keep you from accidentally losing data.

You'll see posts from developers who never understood Access and so resorted to unbound forms because they though that was the only way to control the save. Even they save bad data if they don't validate it correctly and they have to write a lot of unnecessary code to make it happen.

If you don't understand how to control whether or not data gets saved, you might want to view these videos and play with the included database that helps you to understand how Access forms work.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

 

[Isaac]

I know we've argued about this before Pat so I won't start, but , while I agree that there is a way to handle and of course, I know how to handle it, but I still wish it didn't err on the side of saving so quickly at so minimal a trigger. And disagree that that is what users expect.

If I started filling out a quote on Allstate's insurance page, and just began typing "I.s.a." of my name and then closed the computer and walked away, I definitely would NOT expect a quote to be formed. In my experience user happiness is a funny thing. Of course they are happy when the app can do great things, but a more universal rule is they are happy when their expectations are met. When an app surprises them by doing something most apps don't, it's more likely than not to be annoying, not impressive - unless they were trained for it

 

[Marshall Brooks]

@Issac - The current version of Word M365 has this correct, in my opinion. It will not save unless you tell it to do so, but if you just type for 20 minutes or so, it will say "You haven't saved this document yet, would you like to do so now?" (And then it prompts you to save to OneDrive or the cloud and it is difficult to figure out how to save it locally, so not quite perfect yet.)

@Pat Hartman - Agree with what you are saying, but sometimes there aren't really good options.

Initially, we didn't have ANY controls. We just told users "Be careful that you don't type anything you don't want in here, b/c it saves automatically and the old data will be overwritten unless we know about it and can restore it from the backups."

A developer before me came up with an Undo and a Save button and called it good, but he didn't realize that the data was still saved automatically first. i.e. if you clicked the save button you saved the data. If you clicked Undo, you went back to how the record originally was. If you didn't click Undo and also didn't click Save, the record was saved.

The prompt makes it work like other programs and you only see the prompt if you made a change and try to go to a different record or close the DB.

Some fields can't be easily validated. We have a Notes field and it will just contain text. The computer can't logically tell if the text makes sense. If someone changes the field contents to YYYYYYY - there isn't much you can do other than saying "Did you intend to change this field?" which is more annoying than asking "Do you want to save this record?"

There are SOME things you can do. Many databases have a Lock/Unlock button before you can edit a record. Our database we change the background of the field to yellow with the OnChange event and enable the UNDO and SAVE buttons and back to tan and disable the buttons when the record is saved. It doesn't stop the users from putting in bad data, but alert them if something fell on the keyboard and they didn't KNOW they had made a change.

 

[Gasman]

So it is up to you to supply that?
I was just on a website and had to enter the email address that I used and then enter it again to confirm it.
This site was so unsophisticated that I could copy and paste from the first entry to the second.?????
Then I decided to check I had the correct address, and I didn't, so changed the first entry and about to change the second entry, but as soon as I left the first entry, it complained addresses were not the same?

So check was in the wrong place?

I know we've argued about this before Pat so I won't start, but , while I agree that there is a way to handle and of course, I know how to handle it, but I still wish it didn't err on the side of saving so quickly at so minimal a trigger. And disagree that that is what users expect.

If I started filling out a quote on Allstate's insurance page, and just began typing "I.s.a." of my name and then closed the computer and walked away, I definitely would NOT expect a quote to be formed. In my experience user happiness is a funny thing. Of course they are happy when the app can do great things, but a more universal rule is they are happy when their expectations are met. When an app surprises them by doing something most apps don't, it's more likely than not to be annoying, not impressive - unless they were trained for it

 

[Pat Hartman]

I definitely would NOT expect a quote to be formed.

And it wouldn't be because they use validation. They still save the incomplete form though. But, you can be pretty sure they know you started filling out the quote and will send you an email asking you to finish. Look at the way this forum works. Start typing a reply. Then go to some other thread. When you come back to the first one, your partial reply will still be there.

We are talking about an opinion. However, you should not confuse the newbies into thinking that they can't control whether or not a record gets saved. I personally don't care if you use Me.Undo whenever a user makes a data entry mistake as some developers do. Your user might complain though

Agree with what you are saying, but sometimes there aren't really good options.

But there is an excellent option. Use the form's BeforeUpdate event to validate the data. If it is invalid, cancel the save. If you want more control over how a user saves, then give him a Save button. If he doesn't press the save button, you can assume he didn't intend to save and prompt him. That is minimal extra work. But you still need validation code in the Form's BeforeUpdate event.

YOU, the developer, need to protect the user from making a mistake as best you can. That means, you always include validation code in the form's BeforeUpdate event and if you also want the user to only save "consciously", then add the Save button and the code that goes with it.

A developer before me came up with an Undo and a Save button and called it good, but he didn't realize that the data was still saved automatically first. i.e. if you clicked the save button you saved the data. If you clicked Undo, you went back to how the record originally was. If you didn't click Undo and also didn't click Save, the record was saved.

I wonder if he was the developer who wrote more than 5,000!!!!!! lines of code to validate the data but never managed to get any into the form's BeforeUpdate event.

If you want to complain about Access' methodology, you might want to complain about the lack of useful help over views.

Some fields can't be easily validated. We have a Notes field and it will just contain text. The computer can't logically tell if the text makes sense. If someone changes the field contents to YYYYYYY - there isn't much you can do other than saying "Did you intend to change this field?" which is more annoying than asking "Do you want to save this record?"

Of course you can't always ensure that data is correct. But, it is your job to do what little you can do. Don't just throw your arms up and not bother to validate anything. For example, for text fields that are required, you ALWAYS set Allow Zero Length String to No. The user may enter gibberish, but he has to enter something. You always check dates for rationality. It makes no sense for a DOB or DOD to be in the future. You can enter future sales orders but usually, there is a limit to how far in the future would make sense. In other people's databases, I frequently see dates like 1/1/202. As far as Access is concerned, that is a valid date. But, unless you are writing about something that took place in the Roman era, you probably want to flag that as invalid. You can't stop a user from entering Blue when he should have entered Red but you can stop him from ent3ring Green if Green isn't a valid value.

There are SOME things you can do. Many databases have a Lock/Unlock button before you can edit a record.

That is one of those feel good but unnecessary things unless your users are real klutzes or like me, have a cat that jumps up on the keyboard. But changing colors and enabling buttons helps to keep the klutzes from doing real damage.

The reason I say that the lock/unlock is unnecessary is because it still doesn't keep the user from being a klutz. They just have fewer accidents. Using a specific Save button can stand in for this code. If the user doesn't press the Save button, you prompt him rather than just accepting the entry if it is valid.

 

[Marshall Brooks]

@Pat Hartman - We are MUCH closer to being on the same page than you (or I) might have originally thought.

I personally don't care if you use Me.Undo whenever a user makes a data entry mistake as some developers do. Your user might complain though

Valid point. There are numerous places in our database where you can cancel an action. We used to use Me.Undo if you did this - which wiped out ANY fields you had changed since the last change. Now we just set the status field back to the .oldvalue.

and if you also want the user to only save "consciously", then add the Save button and the code that goes with it.

We do one better, although it was annoying to code. We have a Save button, but it is disabled unless you make a change. That makes it very obvious that SOMETHING was changed whether the user intended to do so or not.

I wonder if he was the developer who wrote more than 5,000!!!!!! lines of code to validate the data but never managed to get any into the form's BeforeUpdate event.

Maybe - at the time he knew more about Access than I did - which isn't saying a lot for him.

It makes no sense for a DOB or DOD to be in the future.

I hope my DOD is still in the future, but point taken!!!

The reason I say that the lock/unlock is unnecessary is because it still doesn't keep the user from being a klutz. They just have fewer accidents.

Interesting! I thought that would be something you would recommend. I've seen it on a couple of our company databases by more experienced users than myself. Personally, I found it too many mouse clicks and too annoying - i.e. I have to go to this record, hit unlock, make my changes, hit save, hit lock, go to the next record, rinse and repeat ...

 

[Pat Hartman]

What are the chances of the cat entering a valid value? Usually, the other techniques are sufficient. One of my favorite pictures of my last cat was him sitting on the pile of chips in the middle of the table when we were playing Tripoly. The cat we had when my daughter was young required child locks on all the cabinets. My daughter never opened the cabinet doors and spread cereal all over the entire house when she was little but the cat did.

 

[Marshall Brooks]

If you have the lever-style doorknobs, cats can figure out how to jump up to them and hang on them and open the doors ...

 

[Isaac]

When it comes to users' expectations, I just like apps that keep in line with what they've been visually cued, or otherwise environmentally prepped, to expect.

and yes, I think it's kind of humorous that new people come in here all the time "I can't believe Access saves everything right away", and we try to convince them that all apps do that and it's totally normal, then another 100 new people come in here and say the same thing, and again we try to convince them that it's normal, that all apps do that -- wash,rinse,repeat.

it IS a bit much

 

[Pat Hartman]

Actually, all apps don't do it yet. I just pointed out a couple that do and you love it when they save you from yourself. Think about how less friendly earlier versions of this forum software were when they didn't save your post for you

I'm not sure that the people complain about the save. They only want to know how to control it and since it is controllable (if you know how), it is never a problem.

 

[Marshall Brooks]

Think about how less friendly earlier versions of this forum software were when they didn't save your post for you

Been there, and when there weren't extensions like Typio, etc.

Somewhat darned either way for the software developers. Nobody wants to lose 15 minutes of typing and nobody wants to not be able to "revert to Saved" and drop their changes.

I'm not sure that the people complain about the save. They only want to know how to control it and since it is controllable (if you know how), it is never a problem.

Access isn't only used by developers. Often, people have just heard it comes with Office and someone decides a database would be better than Excel, and maybe we should look into this. (I'm somewhat speaking from my experience.)

People complain when they get a database that was created this way and they say I didn't mean to change this, how do I get it back like it was, and the answer is "Well, it's saved now, we'll have to figure out what it should/used to say and have someone change it back for you. Might take a while."