Where Can a Private VBA Procedure Be Called From Within Microsoft Access? Video Quiz D2.2

Time for a quick VBA quiz. These questions cover a few small but important ideas that come up constantly when you start writing code behind Access forms: procedure scope, passing parameters, choosing between Select Case and If statements, and keeping validation where it belongs. See how many you get before checking the answers.

Grab a piece of paper if you want to keep score. There are five questions, and although none of them are especially evil, VBA has plenty of ways to make a tiny misunderstanding turn into an afternoon of staring at the screen wondering why nothing works.

Question 1: What does declaring a procedure as Private Sub mean in a form's VBA module?

A. Any form or module in the database can call it.
B. Only code in that form's module can call it.
C. It can run only from a command button's Click event.
D. It can be called only from a query.

Answer: B. Only code in that form's module can call it.

A Private procedure is local to the module where it is declared. If you create a helper routine inside a form module and mark it Private, code in that same form module can use it, but other forms and standard modules cannot call it directly. This is useful when the routine exists only to support that particular form. It keeps your code organized and prevents other parts of the database from depending on something that was never meant to be shared.

Question 2: Given a procedure declared like this: Private Sub Calculate(Operation As String), what does the call Calculate "Add" do?

A. It passes the text "Add" into the Operation parameter and runs the procedure.
B. It declares Operation as a new String variable.
C. It assigns the procedure's return value to Operation.
D. It passes both "Add" and "Subtract" to the procedure.

Answer: A. It passes the text "Add" into the Operation parameter and runs the procedure.

The word Operation is a parameter. Think of it as a placeholder the procedure uses to receive information from whatever code calls it. When you call the procedure with "Add", the parameter receives that text, and the procedure can decide to perform addition. The same routine could be called with "Subtract", "Multiply", or "Divide" instead. That is a lot cleaner than creating separate, nearly identical procedures for every calculator button.

Question 3: Why is Select Case often a good choice when one variable can contain several operation names?

A. It automatically converts every operation name into a number.
B. It runs every Case block so all operations are checked.
C. It organizes several alternatives around one expression and runs the matching Case.
D. It can be used only when the variable is numeric.

Answer: C. It organizes several alternatives around one expression and runs the matching Case.

If you have one variable, such as an operation name, with several possible values, Select Case is usually easy to read and maintain. You evaluate the expression once, then give each supported value its own Case section. VBA runs the matching Case and skips the rest. It is especially handy when your choices are mutually exclusive, which is usually the situation with calculator operations.

Question 4: What is the main control-flow advantage of an If...ElseIf chain over several separate If blocks when only one operation should run?

A. ElseIf repeats the first condition until it becomes false.
B. ElseIf causes all conditions to run at the same time.
C. ElseIf automatically returns a value from the procedure.
D. After a true condition is found, later ElseIf conditions are skipped.

Answer: D. After a true condition is found, later ElseIf conditions are skipped.

With a series of separate If statements, VBA evaluates every condition, even if an earlier one already matched. With an If, ElseIf chain, once VBA finds a true condition, it skips the remaining ElseIf tests. That makes it a better fit when only one choice should be performed.

One related gotcha: do not assume that putting multiple tests on one line automatically means VBA will stop evaluating as soon as it finds a true condition. Be careful with expressions joined by logical operators, particularly when later tests could cause an error or call a function you did not intend to run. Write the logic clearly rather than trusting your code to take the scenic route through Mordor safely.

Question 5: Inside a Select Case Operation block, where should a divide-by-zero test go if it applies only to division?

A. Before Select Case, so every operation must pass the division test.
B. Inside Case "Divide", before performing the division.
C. Inside Case Else, after all known operations fail.
D. After End Select, after the division has already occurred.

Answer: B. Inside Case "Divide", before performing the division.

Put validation as close as possible to the operation that needs it. Addition, subtraction, and multiplication do not care whether the second number is zero. Division definitely does. So the zero check belongs inside the division Case, immediately before the calculation happens.

This keeps the code easier to follow because anyone reading it can see the division rule right alongside the division logic. It also avoids forcing unrelated operations through checks that have nothing to do with them. That may seem like a small detail, but small details are where clean VBA code separates itself from a tangled pile of "why is this here?" conditions.

If you got all five, congratulations. You rode into the final battle with a trumpet and a plan. If you missed a couple, no worries. These concepts are covered in more depth in Access Developer Level 2, Lesson 2, where we continue building the calculator application and put this logic to work in a real project.

Watch the embedded video to take the quiz along with the slides, then check out the full class if you want the complete walkthrough and implementation details.

Live long and prosper,
RR

Open the Current Form's VBA Module from the Quick Access Toolbar in Microsoft Access

When you're developing an Access database, you may spend a lot of time working in forms that are already filtered, sorted, and positioned on exactly the record you need. Then you realize you need to make a quick change to that form's VBA code. Switching to Design View just to get to the module is not exactly difficult, but after doing it fifty times a day, it starts to feel like unnecessary exercise.

A handy solution is to add your own button to the Quick Access Toolbar that opens the VBA module for whichever form is currently active. Click the button while working in a live form, and Access jumps directly to that form's code-behind module. No Design View detour, no hunting through the Project Explorer, and no disturbing the form just because you wanted to inspect a little code.

Access does include a few built-in ways to open the Visual Basic Editor. You can add a general Visual Basic button to the Quick Access Toolbar, for example. The problem is that it usually opens wherever VBA was last focused. If you work with multiple modules, forms, reports, or library databases, you may still have to dig around to find the module you actually wanted.

There is also the built-in View Code command. That command is useful, but it is generally available when the object is in Design View. If your form is open in Form View and sitting on the exact customer, order, employee, or whatever record you are working with, changing views can be more disruptive than it needs to be.

The trick is to use a small public VBA function stored in a standard module. A standard module is important because the function needs to be available from anywhere in the database, not tied to one particular form.

The function checks Screen.ActiveForm, which tells Access which form currently has the focus. If there is no active form, attempting to use that property can generate an error, so the function briefly ignores errors while it checks. Then it turns normal error handling back on right away. We are not trying to sweep problems under the rug forever. We just want to safely ask Access whether a form is active.

If there is no active form, the function simply exits. You can leave it silent, which is what I prefer for a toolbar shortcut, or display a message such as "No active form." Either approach is fine. The important part is that clicking the button when a form is not active should not cause an ugly VBA error.

If a form is active, Access normally names that form's class module using the form name with Form_ in front of it. So if the active form is named CustomerF, its VBA module is normally named Form_CustomerF. The function builds that module name by combining "Form_" with the active form's Name property.

It then uses the DoCmd.OpenModule command to open that module. That is the whole heart of the trick. Access can open a module by name, and it can even optionally jump to a particular procedure inside the module. For this shortcut, however, we only need to open the correct form module.

The function is small, but it does something very useful: it looks at the form in front of you right now, figures out the name of its code-behind module, and opens it. The same function works whether you are in a Customer form, an Order form, a Contact form, or any other normal Access form.

Unfortunately, you cannot assign a VBA procedure directly to a Quick Access Toolbar button. Access wants a macro there. Yes, macros. I know. A lot of VBA developers avoid macros whenever possible, and I am often right there with you. But this is one of those cases where a tiny macro is the bridge between the Access interface and your VBA code.

Create a macro with the RunCode action and set its Function Name argument to your public function, including the parentheses. Even though the function does not accept arguments, Access expects the call to look like OpenCurrentFormModule(). Those empty parentheses matter. Access is picky about punctuation sometimes, but at least it is consistently picky.

After saving the macro, customize the Quick Access Toolbar by choosing More Commands, selecting Macros from the command list, and adding your new macro. You can rename it, choose an icon, and set the ScreenTip text to something useful like "Open Current Form Module."

Once that button is in place, the workflow is wonderfully simple. Open a form in Form View, navigate to the record you need, apply your filters, do whatever testing you are doing, and then click the toolbar button when you need code. Access opens the module for that active form immediately.

This does not replace every other way of working with VBA. Sometimes you still want to open the Visual Basic Editor normally, browse modules in the Project Explorer, or use View Code from Design View. This is just a convenient shortcut for a very common developer task.

It is one of those little Access customizations that does not sound life-changing on paper, and it is not. But the small things matter when you do them repeatedly. Saving a few clicks here and there means less interruption, less fumbling around for the right module, and more time actually working on your database.

Watch the embedded video for the complete walkthrough, including the VBA function, the RunCode macro setup, and adding the macro to the Quick Access Toolbar.

Live long and prosper,
RR

Microsoft Access Error 7966: FormatConditions Conditional Formatting Bug in VBA

If your Access VBA code can add conditional formatting rules just fine, but then crashes with Runtime Error 7966 when it reaches the fourth rule, you may not have a bad expression, a bad color setting, or a typo in your code. You may have run into a strange Access bug involving the FormatConditions collection. The especially annoying part is that perfectly legal spaces in an expression can be enough to trigger it. Yep, sometimes a space character gets to ruin your afternoon.

This is a very specific version of Error 7966, so do not assume every 7966 error has this same cause. Access can also throw 7966 if you try to reference a format condition that does not exist, or if you go beyond the maximum number of conditional formatting rules. But if the failure begins with the fourth VBA-created expression rule, there is a recognizable pattern worth checking.

First, a quick clarification about what Access means by FormatConditions. A FormatCondition is one conditional formatting rule attached to a control. For example, you might have one rule that turns an overdue balance red, another that turns paid invoices green, and another that highlights priority customers.

The plural FormatConditions is the collection containing all of those rules for one control. Collections in VBA are generally zero-based, which means the first item is FormatConditions(0), the second is FormatConditions(1), and so on. Therefore, FormatConditions(3) is the fourth rule, not the third. Programmer counting begins at zero, presumably just to keep the rest of humanity slightly uncomfortable.

The bug pattern appears when several conditional formatting rules are added with VBA using acExpression. These are rules based on expressions that evaluate to True or False. The code can successfully create the rules, and the rules may even appear normally in the Conditional Formatting Rules Manager. Then, when VBA later loops through the collection and tries to modify properties such as BackColor or ForeColor, Access can fail when it reaches index 3.

That is what makes this one so deceptive. The code may successfully add six rules. The collection is not empty. The expression syntax is valid enough for Access to accept it. But the moment code tries to work with the fourth item in that collection, Error 7966 appears.

A simple test expression exposes the weirdness nicely. An expression like 1 = 1 is completely valid Access syntax. It always evaluates to True, which makes it useful for testing even though it is not particularly useful business logic. In the reported behavior, however, that expression can cause the failure when multiple VBA-created rules are involved.

Change it to 1=1, with no spaces around the equal sign, and the same code may work normally.

Both expressions mean exactly the same thing. Both are valid. Neither changes the underlying logic. Removing the spaces is not fixing an expression error. It is simply working around an apparent bug in the way Access handles those particular FormatConditions records after they are created in VBA.

If you see this behavior, start by determining exactly where the error occurs. Check whether it happens on FormatConditions(3), meaning the fourth rule. If it fails on some other item, or on a completely different line of code, you may be dealing with another cause of Error 7966.

Next, check how the conditional formatting rules were created. This particular issue is associated with rules added programmatically using FormatConditions.Add and acExpression. Rules created manually in Design View through the Conditional Formatting Rules Manager may not exhibit the same problem.

If your expression is simple, try removing only whitespace that is clearly optional. For example, [Balance] > 0 could be tested as [Balance]>0. Do not go through your entire database and remove every space from every expression like you are trying to save toner. Some expressions need spaces between keywords. Logical operators such as And and Or, for example, need proper separation to remain readable and syntactically correct.

Another practical workaround is to create the conditional formatting rules manually in Design View, then use VBA only to adjust properties on rules that already exist. If your application has a fixed set of formatting rules, that may be the simplest and most dependable option. Let Access build the rules through its normal interface, then let VBA tweak colors or other settings as needed.

If your database relies heavily on conditional formatting, it is also a good idea to test it after Office updates. Access updates can fix old problems, introduce new ones, and occasionally move the furniture around while nobody is looking. Record your Access version and build number under File, Account, and About Access whenever you find a reproducible problem like this.

A useful bug report is more than "Access crashed." Note the exact rule number that fails, whether the rules were created in VBA or manually, the expression text being used, and the Access build involved. A small reproducible test is enormously more useful than a giant production form with fifty controls, fifteen queries, and a moon-phase calculation hidden in the Record Source.

So the short version is this: if VBA-created acExpression conditional formatting rules work until the fourth rule, and Error 7966 appears when you access FormatConditions(3), test the expression text for optional spaces. Something as ridiculous as changing 1 = 1 to 1=1 may get you past the problem.

Watch the embedded video for the full walkthrough and demonstration of the behavior. Hopefully it saves you from spending hours debugging perfectly reasonable VBA code when the real culprit turns out to be a harmless-looking space character.

Live long and prosper,
RR

What Does RGB(0, 0, 255) Mean for Control Text Color in Microsoft Access? Video Quiz A3.1

Time for a quick Access formatting quiz. If you have ever tried to make a control stand out on a form, changed a color property, or pasted a color-picker value somewhere Access did not appreciate it, this one is for you. There are five questions covering ForeColor, BackColor, FontSize, and RGB color expressions.

Give yourself a few seconds to answer each question before reading the answer. No peeking. The Martians are counting on you to accidentally repaint your entire form bright red.

Question 1: Which control property changes the color of text displayed in a text box without changing its background?

A. BackColor
B. ForeColor
C. FontSize
D. Caption

Answer: B. ForeColor. The ForeColor property affects the characters inside the control. BackColor affects the area behind those characters. Think of ForeColor as the ink and BackColor as the paper. You can use both together, of course, but they do two very different jobs.

Question 2: What color does the Access expression RGB(0, 0, 255) produce?

A. Red
B. Green
C. Yellow
D. Blue

Answer: D. Blue. RGB stands for red, green, and blue, in that order. Each value can range from 0 to 255. In this case, red is zero, green is zero, and blue is cranked all the way up to 255. That gives you bright blue.

For example, RGB(255, 0, 0) is red, RGB(0, 255, 0) is green, and RGB(255, 255, 0) gives you yellow because red and green together make yellow. Once you get used to RGB, it becomes much easier than trying to remember random numeric color values.

Question 3: In a SetValue macro action, which expression is the best way to assign bright red to a text box's ForeColor property?

A. =RGB(255, 0, 0)
B. RGB(FF, 00, 00)
C. "#FF0000"
D. =Val("#FF0000")

Answer: A. =RGB(255, 0, 0). The RGB function returns the numeric color value Access needs for a color property. The equal sign tells the SetValue action that you are entering an expression to evaluate, not merely typing text into a box and hoping Access reads your mind.

Question 4: A macro should make a control's text larger when an order reaches a particular status. Which property and value should it set?

A. ForeColor to "16"
B. BackColor to 16
C. FontSize to 16
D. Caption to 16

Answer: C. FontSize to 16. FontSize is the property that controls how large the characters appear. This can be useful when you want to emphasize something important, such as a rush order, an overdue balance, or a customer who has managed to call you seventeen times before lunch.

Question 5: Why can copying a color-picker value such as #FF0000 directly into a SetValue macro expression cause an error?

A. SetValue can change only text values, not formatting properties.
B. The color picker uses hexadecimal text, while the property needs a numeric color value or a color expression.
C. ForeColor can be changed only with VBA, not macros.
D. Access requires all colors to be entered as theme names.

Answer: B. A color picker may display colors in hexadecimal notation, such as #FF0000 for red. That format is common in web design, but it is not automatically a valid Access macro expression. A property such as ForeColor expects a numeric color value, and =RGB(255, 0, 0) is usually the cleanest way to provide one.

So, how did you do? If you got all five, congratulations: the Martians did not get to repaint your database. If you missed a couple, no worries. Control formatting is one of those small Access topics that becomes very handy once you start building forms that need to communicate more than just raw data.

Watch the embedded video for the quiz version and a quick visual walkthrough of these formatting properties.

Live long and prosper,
RR

Can You Delete a Customer With Related Contact Records in Microsoft Access? Video Quiz X2.2

How solid is your understanding of Microsoft Access table relationships? This quick quiz covers explicit relationships, subdatasheets, orphaned records, referential integrity, and what really happens when you try to delete a customer who still has contacts attached.

Give yourself a few seconds to answer each question before checking the explanation. If your records are wandering around without parents, this is a good place to find out why.

Question 1: What is an explicit relationship in an Access database?

A. A relationship saved at the database level between tables
B. A calculated field that combines two tables
C. A relationship created only while a query is open
D. A pinky promise between your records

Answer: A. An explicit relationship is one that is saved at the database level, usually in the Relationships window. Access queries can create joins as needed, but a saved relationship is a global relationship that makes other relationship features available.

Question 2: After creating a one-to-many relationship, where can Access display a subdatasheet of related child records?

A. Only in a report's Page Footer
B. On the parent table, the one side of the relationship
C. On the child table, the many side only
D. Inside every AutoNumber field

Answer: B. Access can display the related child records as a subdatasheet on the parent table, which is the one side of the relationship. For example, a customer record can expand to show that customer's contacts. This is where those little plus buttons come from.

Question 3: What is an orphaned record in a one-to-many relationship?

A. A parent record that has no children yet
B. A record with an AutoNumber primary key
C. A child record whose related parent no longer exists
D. A record that has wandered away from the Navigation Pane

Answer: C. An orphaned record is a child record that still contains a foreign key value, but its parent record is gone. For example, if a contact still has a CustomerID value after that customer has been deleted, the contact is an orphan. Not good. Databases are not orphanages.

Question 4: With referential integrity enforced, what happens if you try to delete a customer who still has related contact records?

A. Access blocks the deletion until the related contacts are handled
B. Access silently changes each contact's CustomerID to zero
C. Access automatically copies the contacts into CustomerT
D. Access deletes the entire database for dramatic effect

Answer: A. Access blocks the deletion. Referential integrity prevents you from deleting the parent customer while related child contacts still exist. You must delete the contacts, reassign them to another customer, or use cascade delete if that is truly what you intend. Be careful with cascade deletes. They are useful, but they can remove a lot of records very quickly.

Question 5: Which setup is required before Access can enforce referential integrity between CustomerT and ContactT?

A. CustomerID must be Short Text in both tables
B. The matching fields must have compatible data types, and the parent key must be unique
C. ContactT must contain at least one contact for every customer
D. Both tables must be printed before creating the relationship

Answer: B. The related fields need compatible data types, and the field on the parent side must be unique, normally a primary key. A common setup is an AutoNumber CustomerID primary key in CustomerT and a Number field, set to Long Integer, for CustomerID in ContactT.

If you got all five, congratulations. Your relationships are probably properly enforced and not wandering around in the rain looking for a missing parent record. If you missed a few, watch the embedded quiz for a quick review, and remember that relationships and referential integrity are some of the most important tools you have for keeping an Access database clean.

Live long and prosper,
RR

How Do You Find Records for One Date With Times in Microsoft Access? Video Quiz A2.2

Time for a quick Access quiz. These five questions cover a few important details that can trip up even experienced users: form events, parent-child records, subforms, control references, and the always-fun problem of dates that secretly include times.

Give yourself a few seconds to answer each one before reading the answer. Keep score if you like. No fair blaming the database when it gets grumpy about referential integrity.

Question 1: When does a form's Before Insert event occur?

A. After the record has been permanently deleted
B. Just before Access inserts a new record
C. Only when an existing record is edited
D. When the database needs a coffee break

The answer is B: just before Access inserts a new record. The Before Insert event is a useful place to check conditions that must be true before a new record is created. It gives you an opportunity to stop or handle a problem before Access writes that new record to the table.

Question 2: Why can Access reject a new order-detail record when its parent order has not been saved yet?

A. Detail records must always be entered directly in a table
B. A subform cannot contain combo boxes until the parent form closes
C. The child record needs a valid parent key to satisfy referential integrity
D. Access requires all orders to contain exactly one product

The answer is C. A detail record is on the many side of the relationship. It needs an OrderID, or whatever foreign key you are using, that points to a real parent order record. If the parent has not been saved yet, it may not have its AutoNumber ID assigned. Without that valid parent key, Access cannot create the relationship, especially when referential integrity is enforced.

Question 3: A new parent form has default values but no saved record yet. What can make Access create and save that parent record before a child record is added?

A. Change a bound field on the parent record and save or refresh that record
B. Hide the parent form and reopen the child subform
C. Add the child record first and let Access calculate the parent ID
D. Change the parent table's primary key into Short Text

The answer is A. Defaults can appear on a new form record without an actual record having been created in the table. That catches people all the time. If you change a bound field on the parent form and then save the record, or otherwise force Access to save it, Access creates the parent record and assigns its AutoNumber key if appropriate. The subform can then use that key for its child records.

Question 4: A macro is running from a subform but needs to use a control on the parent form. What kind of reference is normally required?

A. Just the control name, because all form controls are global
B. A full reference such as [Forms]![ParentF]![ControlName]
C. The table name followed by an exclamation point
D. The control's Caption property in quotation marks

The answer is B. From a subform, you generally need a full reference to reach a control on another form, such as [Forms]![ParentF]![ControlName]. There are other valid ways to do it depending on where the macro or expression is running. For example, Parent!ControlName can be appropriate from inside a subform. But among these choices, the fully qualified Forms reference is the correct one.

Question 5: An OrderDate field stores both dates and times. What criteria most reliably finds all orders placed on one particular date?

A. OrderDate = the requested date
B. OrderDate Like the requested date
C. OrderDate > the requested date
D. OrderDate >= the requested date And OrderDate < the next day

The answer is D. This is the reliable way to find every record from a particular calendar day when the field also contains a time value. An equality test only finds records stored at exactly midnight. An order placed at 2:37 PM is not equal to the same date at 12:00:00 AM, even though Access may display both as the same date depending on the format.

The correct approach is to search for values that are greater than or equal to the start of the requested date and less than the start of the following date. In other words, include everything from midnight on the requested day up to, but not including, midnight tomorrow. This avoids missing records with times and avoids the messy temptation to use an end-of-day value such as 11:59:59 PM.

How did you do? Five out of five means you have successfully named a new species and survived its welcome hug. If you missed a few, no worries. These are exactly the kinds of little Access details that become important once you start building real forms with related data.

The embedded video has the full quiz presentation, and these topics are covered in more depth in Access Advanced Level 2, Lesson 2.

Live long and prosper,
RR

What Is the Primary Purpose of DoCmd.OpenForm in Microsoft Access VBA? Video Quiz D1.3

Time for a quick Access VBA quiz. This one covers a handful of beginner developer concepts that come up constantly once you start putting buttons, forms, and a little code into your database. See how many you get right before checking the answers.

The questions focus on opening forms with VBA, where button code belongs, what optional arguments mean, filtering a form as it opens, and why reusable procedures are your friend. In other words, the stuff that keeps you from copying the same three lines of code into seventeen different buttons. We've all been there.

Question 1: What is the primary purpose of the DoCmd.OpenForm command in Access VBA?

A. Open a specified form
B. Create a new table
C. Print the active report
D. Import records from Excel

Answer: A. Open a specified form.

DoCmd.OpenForm does exactly what its name suggests: it tells Access to open a form. You provide the form's name, and Access displays it for the user. As you get more comfortable with the command, you can add arguments to control things such as the view, data-entry mode, window mode, and which records should be displayed.

Question 2: Where would you normally place VBA code that should run when a user clicks a command button on a form?

A. In the button's On Click event procedure
B. In the table's primary key property
C. In the form's Record Source query
D. In the Navigation Pane

Answer: A. In the button's On Click event procedure.

A command button has an On Click event specifically for this purpose. When the user clicks that particular button, Access runs the code assigned to its event procedure. The procedure will normally have a name ending in _Click. That is where you might put a simple OpenForm command, validation logic, a confirmation message, or a call to another reusable procedure.

Question 3: In a VBA command's argument list, what do square brackets around an argument usually mean?

A. The argument is optional
B. The argument must contain a date
C. The argument is a table name
D. The argument can only be used in a query

Answer: A. The argument is optional.

When you look at Access VBA documentation and see an argument inside square brackets, that means you can leave it out. Access will use its normal default behavior. This is why a simple command can be as short as opening a form by name, while the same command can also be expanded later when you need more control.

Question 4: When opening a form, what is a WhereCondition commonly used for?

A. Showing only records that meet specified criteria
B. Renaming the form before it opens
C. Changing the form's design permanently
D. Creating a relationship between tables

Answer: A. Showing only records that meet specified criteria.

A WhereCondition filters the form as it opens. For example, if the user is looking at a customer in a list and clicks a button, you can open the customer form directly to that customer's record instead of opening the form to every customer in the database. This is one of the most useful reasons to use OpenForm from a button.

Question 5: Why is it often better to put repeated VBA instructions into a separate Sub procedure?

A. It keeps the shared code in one place
B. It automatically creates a new table
C. It prevents users from editing records
D. It removes the need for event procedures

Answer: A. It keeps the shared code in one place.

If several buttons need to perform the same task, putting that task in one separate Sub procedure makes your database easier to maintain. If the process changes later, you update it once instead of tracking down duplicate code scattered across multiple forms and event procedures. Less duplicate code means fewer opportunities for one button to get forgotten and quietly do something different. Access is quite good at quietly letting you create that kind of problem.

If you got all five, congratulations, you know where your towel is. If any of these questions gave you trouble, watch the embedded video and review the concepts. These are foundational skills for working with forms and VBA in Microsoft Access.

Live long and prosper,
RR