Computer tutorials, tips, and tricks to help you learn Microsoft Excel, Access, Word, and lots more. Visit our full site at www.ComputerLearningZone.com.
Saturday, February 14, 2026
dotnet CLI list
from Computer Learning Zone News https://599cd.com/3784
Saturday, February 7, 2026
Saturday, January 31, 2026
Friday, January 30, 2026
Stop Storing Payments by Month in Microsoft Access: The Beginner Table Mistake That Breaks Reports
If you started your billing database in Microsoft Access like an Excel spreadsheet, you're not alone... but you're probably making reports WAY harder than they need to be. In this week’s TechHelp Quick Queries, I cover a classic beginner mistake (and a simple upgrade that makes your whole database smarter).
The problem being addressed:
One of my students built a billing system where each customer record has separate fields for January, February, March, etc. It looks clean at first, but the moment you want to answer a basic business question like "How much money did we collect today?" everything starts falling apart.
Why common solutions fail:
When you store repeating monthly payments as separate fields, every new need creates more clutter: a paid flag for each month, then a date paid for each month, then an amount paid for each month... and suddenly one table record turns into a monster. Reporting becomes painful because you have to check a dozen different fields just to total deposits for one day. And when the next year rolls around? Now you're duplicating customer data just to start over with another set of month fields.
The practical solution presented:
The better approach is using a related payments table. Instead of one record holding twelve months of payment fields, you store each payment as its own record with the customer ID, payment date, and amount paid (and optionally what billing period the payment applies to). This makes end-of-day reports simple, lets you query payments by date instantly, and keeps your database scalable without redesigning everything every January.
Who the content is for:
This one is for beginners (especially anyone transitioning from Excel to Access) who are building billing, membership, or subscription databases. If you've ever created one table and started adding "JanPaid, FebPaid, MarPaid..." columns, this video will save you a lot of future headaches.
What is coming next:
I also answer a bunch of other great questions in this episode, including tabbed documents vs overlapping windows, Power Query merge performance compared to Access joins, combo box list caching, fixing report footer gaps, hiding tables with VBA (and why it is not real security), and whether Access is still worth learning in 2026. Lots of good stuff in this Quick Queries!
Live long and prosper,
RR
Thursday, January 29, 2026
Is Nothing: Optional Form Parameters in Access VBA - How to Avoid Crashes and Keep Your Code Clean
Ever write a nice clean VBA routine in Microsoft Access, only to have it blow up the second you try to make it "optional"? Yeah... this is one of those sneaky little gotchas that can waste an entire afternoon and leave you staring at your screen thinking, "Why is this even a thing?" In this lesson, I show you how to safely handle optional form parameters without rewriting your entire database.
The problem
A student asks a great question: how do you write one global "status message" routine that works across multiple forms, without duplicating code everywhere? This is a super common situation. You might have a little status box that displays messages like "Saving record..." or "Export complete" with a timestamp, and you want that same routine to work on your Main Menu, your Customer form, and anything else in your database.
Passing a form reference into your status routine is a great solution. It keeps your code reusable, clean, and easy to maintain. But then you hit the next logical step: "What if I want the form parameter to be optional?" Maybe you have hundreds (or thousands) of existing calls to your status routine, and you do not want to go back and update every single one just to add a form argument.
Why the common solutions fail
This is where most people run into trouble. Optional parameters are easy with text and numbers, but forms are different. A form is an object, and object variables don't behave like strings, dates, or numeric values.
So what happens when you try the usual tricks? Access throws errors like "Argument not optional" or "Object variable or With block not set." And if you try to handle it using common methods people use for other parameter types, VBA will fight you the whole way. It's frustrating because the routine seems correct until you run it without that form reference.
The practical fix (without rewriting everything)
In the video, I walk through the proper way to define the form parameter as optional, and then safely detect when it wasn't passed in at all. Once you can detect that situation reliably, you can automatically default to a specific form (like your Main Menu) and keep the rest of your existing code working exactly as-is.
This one little technique has a huge payoff: it prevents the error, keeps the routine reusable, and saves you from doing a painful global search-and-replace across your entire project.
Who this is for
This lesson is perfect if you are building Microsoft Access databases with multiple forms and you want cleaner, reusable VBA code. If you're the "lucky" person who got assigned the warehouse database (or any line-of-business system), and you're trying to make your UI more professional with consistent status updates, this is right up your alley.
Coming next
At the end, I also mention a cool upgrade you can add to this concept: automatically detecting whether the form you're working with has its own status box, and using it if available. That's a more advanced technique, and if you'd like to see that version, leave a comment and let me know. I may turn it into a follow-up video.
Live long and prosper,
RR
Wednesday, January 28, 2026
Almost Ready!
from Computer Learning Zone News https://599cd.com/SQLSA01
Tuesday, January 27, 2026
Ambiguous Name Detected in Access VBA: Fix Duplicate Procedure Names Fast (Status, Compile, Find)
If Microsoft Access suddenly throws "Ambiguous name detected" at you, don’t panic. This one looks scary, but it’s usually a two-minute fix once you know what it really means.
The problem: You run your database (or click a button) and VBA stops cold with the message "Ambiguous name detected". This happens when Access finds two different procedures with the exact same name somewhere in your VBA project, and it can’t tell which one you meant.
Why this happens (and why it’s so common): Most of the time this shows up after you copy and paste code from somewhere else, maybe from a template, a random website, or even my code vault. You add a new module that contains a procedure name you already had (like Status, Update, Process, etc.), and now Access has two matching names. If both are Public, VBA throws up its hands and refuses to guess.
Why common "fixes" fail: People often assume the copied code is broken, or they start deleting random things until the error goes away. That’s a great way to create brand new problems. This isn’t a “bad code” issue, it’s a duplicate name issue. Until you find the duplicate and resolve the conflict, the database will keep failing to compile and your code won’t run.
The practical fix: First, run Debug > Compile. This forces Access to identify the conflict immediately instead of letting it surprise you later. Then use the VBA Editor search (Ctrl+F) and switch the search scope to Current Project. Search for the procedure name mentioned in the error message and you’ll find both copies.
Once you find the duplicate, you have a few options: Rename one of the procedures, delete the one you don’t need, or change the scope so it’s not visible project-wide. For example, making one version Private prevents the rest of the database from seeing it, which can eliminate the conflict while still letting that module use it internally.
One extra "gotcha" I cover: Sometimes you’ll create a procedure with the same name inside a form’s code module without realizing it. In that case, code behind the form can take priority over a global module, which leads to confusing behavior. When needed, you can explicitly call the global version using the full module reference (like GlobalMod.Status).
Who this video is for: This is a VBA developer-level tip for anyone building Microsoft Access databases, especially if you’re the kind of person who grabs working code snippets and pastes them into an existing project (no judgement... but yes, I’m looking at you).
What’s next: If you want to go deeper, I recommend learning more about scope and visibility (Public vs Private), because this exact issue is one of the most common “copy/paste coding” problems Access developers run into. And yes, the best habit you can develop is this: Debug - Compile once in a while (especially right after adding new code).
As always, post a comment and let me know how you’re using this in your database.
Live long and prosper, my friends. RR
Monday, January 26, 2026
Visible Sleep Countdown Timer in Microsoft Access (VBA SleepSec + Status Box Upgrade)
Ever had your Microsoft Access database "pause" for a few seconds and make you think it just crashed? Yeah... your users think that too. In this TechHelp video, I show you a simple little VBA upgrade that makes your database look alive and professional: a visible countdown timer right on the screen while your code is waiting.
The problem: Sometimes your Access code needs to wait. Maybe you're automating something (like opening another app), waiting for a file to finish copying, or giving Windows a second to catch up. The trouble is, when Access just "sleeps" with no feedback, the database looks frozen. Users start clicking things, mashing buttons, and assuming the worst.
Why common solutions fail: A basic hard pause (like using a straight Sleep call) locks things up visually. The screen doesn't update, you don't get status messages, and the user has no clue what's happening. Even worse, they may assume your database is broken when it's really just waiting normally in the background.
The practical solution: I take the SleepSec function I built in my earlier sleep video and upgrade it to include an optional visible countdown timer. Instead of waiting silently, Access displays something like "Wait 5... Wait 4... Wait 3..." so the user can see that the program is still working and how long the pause will last.
This improved version loops one second at a time, optionally calls DoEvents so the interface stays responsive, and uses my Status Box to show the countdown message right on the form. It's a small change, but it makes your database feel a lot more polished.
Who this is for: This is a Microsoft Access developer tip, so you'll want to be comfortable with a little VBA. If you're already using SleepSec, status messages, or doing any kind of automation (SendKeys, file handling, external apps, etc.), this is a great quality-of-life upgrade that you can reuse everywhere.
What’s coming next: In the extended cut, I show members how to display the countdown without printing multiple lines, so it updates in-place like an old-school DOS app (super clean and professional). Also, this function (SleepSeconds) is available in my Code Vault, and I’ve got tons more reusable VBA modules in there for Access developers.
If you're going to make Access wait, don't leave your users staring at the screen wondering if your database just died. Give them a countdown and keep things feeling alive.
Saturday, January 24, 2026
Friday, January 23, 2026
Access D51 Lesson 05
from Computer Learning Zone News https://599cd.com/ACD51-5
Access D51 Lesson 01
from Computer Learning Zone News https://599cd.com/ACD51-1
Access D51 Lesson 03
from Computer Learning Zone News https://599cd.com/ACD51-3
Access D51 Lesson 04
from Computer Learning Zone News https://599cd.com/ACD51-4
Access D51 Lesson 06
from Computer Learning Zone News https://599cd.com/ACD51-6
The Microsoft Access Security Myth: Can You Really Hide Tables From Users?
If you think hiding tables in Microsoft Access makes your database secure, I’ve got some bad news for you. In this week’s TechHelp Quick Queries, we bust one of the biggest security myths in Access and talk about what actually protects your data.
The Problem: A lot of people assume they can “secure” an Access database by hiding tables, password protecting objects, or relying on the Navigation Pane being out of sight. The idea is that users can work with forms and reports, but won’t be able to see or get to the raw data behind the scenes.
Why Common Solutions Fail: Hiding objects in Access isn’t security. If someone has the database file, they can usually access the data with the right tools, especially if the tables are stored locally inside the database. Even passwords and simple Access-only tricks often give a false sense of protection. In other words, hiding your tables is more like closing the curtains than locking the doors.
The Practical Solution: If protecting data actually matters, you need real separation and real permissions. That means using a split database (so each user has their own front end) and securing the data in a proper backend. The best long-term approach is a database server like SQL Server where you can apply user-level security and control who can see what.
More Questions Covered: After that, we jump into a bunch of great viewer questions, including how to build menu searches that let users type just part of a part number (wildcards and “search as you type”), the pros and cons of tab controls, what happens when Amazon changes their website layout when you’re copying webpage data, and how to handle 20 users running the same database on different versions of Access.
Templates Like Northwind: We also talk about why Microsoft templates like Northwind are more like feature demos than starter databases. They’re well built and show what Access can do, but the moment you try to bend them to your real business, you often end up fighting macros, hidden logic, and design decisions you didn’t make.
Who This Video Is For: If you’re building Access databases for clients, sharing a database across multiple users, trying to protect customer data, or just wondering why certain “simple fixes” turn into big headaches, this episode is for you.
Coming Next: I’ve got more videos coming soon on SQL Server integration, better backup strategies, and more automation tools (including some fun new projects I’m experimenting with). So if you’ve got a question, leave it in the comments and it might show up in next week’s episode!
Thursday, January 22, 2026
Smart Combo Boxes 2
from Computer Learning Zone News https://599cd.com/SmartComboBoxes2
Wednesday, January 21, 2026
How to Build Smart Combo Boxes in Microsoft Access That Load Faster
If your Microsoft Access forms feel slow or clunky, there is a good chance your combo boxes are loading far more records than they actually need. In this TechHelp video, I show how to build smarter combo boxes that load only what is necessary, making your forms faster, cleaner, and easier to use.
The problem
Many Access developers load entire tables into combo boxes by default, even when those tables contain thousands or tens of thousands of records. This can slow forms down significantly, especially over a network or with a SQL Server back end, and it also creates clutter for users who usually just want to see the current value.
Why common solutions fall short
Filtering combo boxes manually or relying on users to search through long dropdown lists still means loading a lot of unnecessary data. Inactive records, old customers, or unused values continue to hurt performance and usability unless you deliberately control what gets loaded.
The practical solution
In this video, I demonstrate how to build smart combo boxes by changing the RowSource dynamically based on context. When viewing an existing record, the combo box loads only the current value. When adding a new record, it loads only active records. Simple command buttons allow the user to switch to active or all records on demand, giving flexibility without sacrificing performance.
Who this video is for
This is a developer-level TechHelp video aimed at Access users who are comfortable with VBA and want better control over form behavior and performance. If you work with large tables, multi-user databases, or linked data sources, this technique can make a noticeable difference.
What is coming next
Building on this idea, there are other videos that explore advanced combo box techniques, dynamic filtering, and performance optimization in more depth. And if you ever search YouTube or Google for a Microsoft Access topic and do not see one of my videos, let me know. I will make one.
Tuesday, January 20, 2026
How To Create A Self Cleaning Log In Microsoft Access And Automatically Delete Old Records
If your Microsoft Access database has been getting slower over time and you cannot quite put your finger on why, there is a good chance the problem is a quiet one growing in the background. Log tables do their job well, but if you never clean them up, they can slowly bloat your database and drag down performance.
The problem
Many Access databases use log tables to track user activity, logons, logoffs, or other events. These tables grow a little bit every day, often without anyone noticing. After months or years, the log can become massive, making the database slower and harder to maintain.
Why common solutions fail
Most people either ignore the problem or rely on manual cleanup. That usually means opening the table occasionally and deleting old records by hand, which is easy to forget. Others build a delete button that nobody ever clicks. In the real world, manual maintenance almost never happens consistently.
The practical solution
In this video, I show you a simple way to have Microsoft Access automatically remove old log records based on age. The cleanup runs quietly in the background, keeps only the most recent entries you care about, and prevents the log table from growing forever. No babysitting required.
Who this is for
This video is for anyone using Microsoft Access to log user activity or other events, especially if the database has been in use for a long time. You only need a basic understanding of VBA to follow along.
What is coming next
For members, the extended cut goes further by turning this into a reusable logging system, automatically creating missing log tables, and making the solution easy to drop into any database. Details are covered in the extended cut for paid members.
Monday, January 19, 2026
Access D51 Lesson 07
from Computer Learning Zone News https://599cd.com/4321
ACD51 Lesson 07
from Computer Learning Zone News https://599cd.com/ACD51-7