@CatDad Welcome
I am a cat person but I'm allergic and so had to give them up so I don't have any now. I didn't even know there were cat shows.
Since you come from a programming background, you can probably figure stuff out but as
@NauticalGent mentioned, there really is an "Access way" and it is ever so much easier than what most experienced people realize. You're not afraid to code and so given that VBA is probably one of the simplest of the programming languages, you can almost figure it out on the fly. So, your first inclination will be to code your way around a problem. Frequently, you'll succeed but it will be harder than it should have been because you will almost certainly be fighting with Access. My background is old. COBOL/CICS and I came to Access around 2.0 in the early 90's when one of my clients suggested it as an option for an application they wanted. The application linked to DB2 (the IBM RDBMS that runs on mainframes) on the mainframe and for me it was love at first sight. That to me, at that time, was totally amazing. I could connect to the mainframe database and update it with Access. I was hooked. The concept of Access Forms is very similar to the real time applications (what we used before the web when our users were all over the country) I typically developed using CICS or IMS/DC. But, moving from a procedural language to one that was event driven was something of a challenge.
The most important concept to understand about Forms is that your code is not in charge. Your code is written as subroutines connected to Events. The mainline code is not visible to you. You can't change it. You need to understand how events are triggered and that will help you with placing your code in the correct event so that it works for you and with Access. There is always a "correct" event. The programmers who wrote the code that actually manages the form gave you hooks in the form of Events where you can hang your code which deals with "why" that event was triggered.
Then you need to understand that the most important Form level event is the BeforeUpdate event. This event is like the flapper at the bottom of a funnel. If the flapper is open, the record gets saved. If the flapper is closed, the record does not get saved. Newbees work themselves into a frenzy trying to control the save process. Don't get wrapped up in that. Access makes it a personal mission to save data and so it does it sometimes in places where you might not expect it to. So, you control that by "catching" the save in the BeforeUpdate event which is the last event to run before the record is actually saved. Therefore, you can validate data and determine if nothing is missing and then let Access proceed to save the record or you can stop Access by using:
Cancel = True
This leaves the record dirty and the user will get to fix his error, which presumably you have given him a message about.
I've included a link to a sample database I created. I wanted to make a video describing why the Form's BeforeUpdate event is so important and ended up creating a very useful database that will help you to understand what is going on with your forms. There are three videos. Two were made to explain various events but the third (the youtube video) is a presentation to an Access user group. It is probably the most entertaining because it has the most viewer interaction but do watch at least one of the videos so you have an understanding of how to use the sample app and see what it is showing you. In the first video, I was working with
@Uncle Gizmo and he was playing my audience and asking questions. We recorded it live and that is pretty much what you see. Uncle was kind enough to do some editing to clean up mistakes but it is essentially unrehearsed and so not particularly slick. But during the process we both discovered new stuff about which events run when.
Have fun. I love Access because I'm a lazy bum. It does so much for me that even after all these years I still appreciate it. Access sometimes seems a little long in the tooth and I do wish MS understood what a powerful and unique tool it is and marketed it better but the fact that they don't make a lot of changes is sometimes a godsend given that the less stuff they change the less likely they are to break something critical.
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
If you have questions regarding the Events logger app, please @ me so I am notified regarding the post and post them in the samples forum so others who have downloaded the samples can see your questions or comments.
I have other samples there which you might find interesting.
