Computer tutorials, tips, and tricks to help you learn Microsoft Excel, Access, Word, and lots more. Visit our full site at www.ComputerLearningZone.com.
So yesterday I decided to make what I thought would be a quick, harmless, “ten-minute improvement” to the website database. You know the kind. The little tweaks you do just to smooth things out. Streamline a process. Make it cleaner. More efficient. Cross all the i’s and dot all the t’s. Yes, I know that’s backwards. I say it that way on purpose. It’s tradition at this point.
Anyway, this particular process dates back to Ancient Richard Times. We’re talking years ago, before I knew any better. It runs a recordset loop and, as part of that loop, it actually opens up the customer form to do some work. Horrible practice by today’s standards, but it’s been surprisingly bulletproof. Maybe once a month it locks up, and my Watchdog utility steps in, restarts Access, and life goes on.
But yesterday I watched it happen and thought, “Well that’s silly. I can fix that.” No need to open a form. Just handle everything in the background with a proper recordset. Cleaner. Faster. More elegant.
Famous last words.
I rewrote it. Beautifully, I might add. Proper error handling. Nice clean logic. The kind of code you sit back and admire for a second before moving on. What I did not realize, however, was that other parts of the system were quietly depending on that form being open. Not for the main task, but for things that happened afterward.
So now this function broke that function, which broke another procedure, which triggered a cascade failure worthy of a warp core breach. At one point I seriously considered restoring from the pre-change backup and calling it a night. Crawl into bed. Pretend none of this ever happened.
But no. The perfectionist in me took the conn.
So down the rabbit hole I went. Fix this dependency. Rewrite that routine. Adjust the follow-up process. Then I discovered the user upload procedure, the one that pushes data from my local Access database to the web server, also relied on the old behavior.
That fix broke credit card processing.
Because of course it did.
Next thing I know it’s 4:00 in the morning. I’m squinting at the screen with my one good eye, testing transactions, running uploads, watching logs scroll by. I even had to switch the VBA editor into dark mode because the white background was burning a hole straight through my skull. So if you notice future videos looking a little more “night shift friendly,” that’s why.
The good news is by Monday morning everything was stable again. Systems operational. Engines back online. No customers the wiser.
But there were a couple of solid takeaways from the adventure.
First, backups are life. I had multiple. I made another one right before starting the “ten-minute fix.” At any point I could have rolled back instantly. That safety net makes deep surgery possible.
Second, it’s always the ten-minute changes. Every time you think, “I’ll knock this out before dinner,” you are lying to yourself. That is never a ten-minute change. That is a six-hour marathon wearing a fake mustache.
And the final lesson, especially for anyone doing client work, is about estimates. Never give the optimistic number. Never tell the captain it’ll take two days.
You tell him two weeks.
Because when you pull it off in five days, you look like a miracle worker. Scotty understood this. Reputation management through strategic pessimism. Don’t be Geordie giving accurate engineering timelines.
Attention, Access developers - here's an event you'll actually want to put on your calendar. If you're serious about Microsoft Access, whether you're building databases as your full-time gig or you're just the "Access guy" everyone in the office calls when anything needs fixing, there's something big coming up that you'll want to know about: Access Day 2026.
This isn't just another generic tech conference where you have to sit through hours of buzzword bingo and hope that someone, somewhere, mentions something relevant to Access. No, Access Day is the real deal: a one-day event, happening Friday, March 27, 2026, in the Redmond, Washington area - that's right in Microsoft's backyard. If you're within road trip range or you've been waiting for a reason to visit Seattle, this is it.
I attended Access Day previously and it's honestly some of the best time you can spend with the Access community. There's a mix of presentations, lively hallway conversations, and, best of all, actual members of the Microsoft Access team are there. They share what's coming next, answer questions, and sometimes even soak up a little developer feedback (they're good sports about it).
Sessions include starting and growing a consulting business, taking over and maintaining existing Access applications, working with Azure SQL for secure remote access, solving the "New Outlook" problem with Graph API authentication and MFA, and using AI as an Access development assistant to export objects, analyze code, and identify performance and security issues.
Of course, the Microsoft Access product team will be there giving updates and sneak peeks at what's next for Access. It's a rare chance to ask them questions directly - just try not to overwhelm them all at once.
There's even talk of an optional dinner afterward, so you can keep the geek talk rolling late into the evening. If you've ever wanted to debate DAO vs. ADO over a nice steak or just pick up a few new tricks from fellow developers, this is your crowd.
Registration is open now. I'll drop a link with the details below. If you're able to make the trip, I highly recommend it - not just for the presentations, but for all the stuff that happens in between. You'll leave with new ideas, new connections, and maybe a couple of new friends who actually want to talk about Access as much as you do.
If you want the full walk-through and all the details, check out the video above. Hope to see you there!
Managing files directly inside your Microsoft Access database doesn't have to be a clunky experience. Imagine being able to drag and drop files, preview them instantly, and launch anything - from documents to folders, web links, or even other Access databases - right from your Access form. Taking your database to this professional, super-productive level is completely doable, and it's exactly what we're tackling today.
Let's dive right into creating a file drop system that's genuinely useful. The first step is setting up the ability to click and drag any file onto a form, which isn't just a party trick - it keeps your files organized and tightly integrated. With each dropped file, you'll have Access automatically store and track it in a designated folder, all from the comfort of your database interface.
Now comes the fun part: transforming simple file storage into a user-friendly preview and launch system. The magic starts with image thumbnails and recognizable icons for common file types - Word, Excel, PDF, and so on. This lets you scan your files visually instead of decoding mysterious file names. Want to launch a file? Just click its thumbnail. Whether it's a document, a web link, a folder, or even another Access database (with custom command-line settings, no less), you're covered with one centralized interface.
But we're not stopping at just previews. Let's talk about performance. Quick previews mean no awkward waiting for giant attachments to load, even if you're dealing with folders or hyperlinks and not just traditional files. The system also gracefully supports unknown file types - so, you know, you're never stuck with the dreaded blank icon of confusion.
Automation really makes this setup shine. Integrating with Excel and Word, you'll set up routines to open a particular worksheet directly, or jump straight to a header in a Word document, or even trigger a search as soon as the file launches. This isn't just convenient - it's a major time-saver if you routinely work with large or complex documents.
So if you're interested in elevating your Access app into a full-fledged file management powerhouse, this is the way to go. It saves time, reduces errors, and just plain feels cool. If you want all the gritty details, hit play on the video above for a step-by-step walkthrough. And remember, you can always reach out via my website or comment below if you run into any snags.
Enjoy building your own next-level Access file system!
This morning's reflection came to me the way many of them do. Coffee in hand. News feed scrolling. Brain booting up somewhere between "system check" and "engage warp drive." And then I hit a headline that made me stop mid-sip and just stare at the viewscreen.
The current administration has reversed the EPA's long-standing "Endangerment Finding" on greenhouse gases. In plain English, that's the official scientific determination, first made in 2009, that greenhouse gases like carbon dioxide and methane pose a danger to human health and the environment. That finding wasn't based on opinion. It wasn't based on politics. It was built on decades of atmospheric data, epidemiology, climate modeling, and peer-reviewed research. In other words... actual science.
And here's the key point that keeps echoing in my head: this isn't some unresolved debate in the scientific community anymore. Among climate scientists, the role of greenhouse gases in driving climate change is settled science. You'll always find outliers. You can find someone who thinks the Earth is flat too, but the overwhelming consensus, backed by measurable data, is clear. Greenhouse gases trap heat. Rising concentrations correlate with rising global temperatures. That warming has downstream effects on weather, oceans, agriculture, and public health.
So when a policy decision comes along and effectively says, "We're no longer recognizing that scientific conclusion," it's not just regulatory change. It feels like looking at a warp core breach alarm and deciding the computer is being dramatic.
Now, I try very hard not to turn this platform into partisan space politics. I've got students across the entire political spectrum, and that's exactly how it should be. You can believe whatever you want about taxes, spending, regulations, or the proper size of government. Reasonable people can disagree on policy outcomes all day long.
But science isn't supposed to be partisan. Science is the operating system everything else runs on.
And that's where this one sticks in my craw, because computers, databases, and software development, the stuff we do here every day, are built entirely on scientific principles. Boolean logic. Electrical engineering. Semiconductor physics. Error detection. Mathematical modeling. You don't get to vote on whether binary works. Imagine trying to run Access on "feelings" instead of structured query logic. Your SELECT statements would return whatever the server felt like giving you that day.
That's not how reality works. The scientific method is why your code compiles, your GPS knows where you are, and your backups restore when things go sideways. We test hypotheses. We gather data. We replicate results. We refine models. That process is the closest thing humanity has to a universal debugging tool.
And when I look at this EPA reversal, it doesn't feel isolated. It feels like part of a broader pattern we've seen over the years. Climate regulations rolled back or weakened. International climate agreements abandoned or sidelined. Scientific advisory panels reshuffled or reduced. Environmental monitoring and research programs cut back. Pollution and chemical exposure limits loosened in certain sectors. Public rhetoric that frames established science as optional, exaggerated, or politically motivated.
You can argue the economics of any one of those decisions. You can argue regulatory burden. You can argue industry impact. Those are valid policy conversations. But dismissing or overriding the underlying science itself? That's where it veers into "we're ignoring the sensors because we don't like the readings." On the Enterprise, if Geordi tells Picard the hull integrity is down to 20%, Picard doesn't say, "Well, let's get a second opinion from someone who doesn't believe in hull breaches." He orders repairs. Because physics doesn't negotiate.
That's really the heart of today's log. This site, this community, everything we do here, is rooted in scientific thinking. You build and test your database. You validate your inputs. You verify your outputs. You trust repeatable results over gut instinct. That mindset is what makes someone a good developer, a good troubleshooter, a good systems architect.
You don't fix bugs by ignoring error messages. You don't optimize performance by pretending metrics don't matter. And you don't advance civilization by sidelining the scientific method when it becomes politically inconvenient.
Now, I'm not saying science has all the answers and that it's perfect. It doesn't, and it's not. Science is iterative. Models improve. Data gets refined. Conclusions get updated as new evidence comes in. That's the strength of it, not the weakness. It self-corrects. It's the best thing we've got for understanding the universe and how things work.
But throwing out a 17-year scientific foundation that's only grown stronger with time? That feels less like refinement and more like unplugging the computer because you didn't like what was on the screen. At the end of the day, whether you're writing code, building databases, or piloting a starship, reality still runs on the same core engine: evidence, measurement, and reproducibility.
Ignore that engine long enough... and eventually something critical stops working.
Ever feel like your Access database is a little... slow on the draw? There's one powerful VBA command that can trick your database into looking lightning fast, but if you use it wrong, you'll freeze your entire application faster than you can say "force quit." On top of that, let's answer some burning questions about slow queries, optional filtering, modernizing with SQL Server, safely sharing front ends, exporting all your code, and a bunch of rapid-fire troubleshooting tips. Ready? Let's make your Access life easier - and safer.
If you've ever noticed annoying flicker or laggy form redraws during heavy processing, you might be tempted to use DoCmd.Echo False in VBA. This command turns off screen updating to speed up code that rapidly updates forms or records - makes everything look smooth as butter. But here's your warning: if you turn Echo off and forget to turn it back on (or your code errors out), your whole Access application looks frozen. It's not technically locked forever, but you can't interact with the interface until you restore Echo back to True. Trust me, every Access developer learns this the hard way - at least once!
So, how do you avoid disaster with Echo? First, NEVER sprinkle DoCmd.Echo False into your code without also ensuring DoCmd.Echo True gets called no matter what. Good error handling is your best friend here. Wrap your loops with error traps: if the code crashes, Echo turns back on before exiting. If you ever do find your screen locked in developer mode, try opening the VBA editor, use the Immediate Window and type DoCmd.Echo True. Sometimes, that'll bring Access back to life. But always back up before playing with Echo - or risk losing an afternoon to debugging your own mistake.
For a safer alternative, Me.Painting = False only shuts off redraw for the active form, not the entire app. Use this if you just want to prevent flicker during updates and you don't need global screen changes. It's much less risky and saves you from a global freeze if things go sideways.
Now, let's shift gears and talk databases in the cloud. A common misconception: "My web host says they support Access! Can I just upload my backend ACCDB and connect to it from home like SQL Server?" Sorry, not really. Access is file-based, expecting super-fast local file sharing. Stick an ACCDB on your web server and connect via HTTP or FTP and you're just begging for data corruption - especially with multiple users. Web hosts support hosting ACCDB files only for local web code (like ASP.NET) - not for remote Access desktops over the Internet. If your goal is true remote data, you want SQL Server (or similar). That's built for cross-network connections, secure logins, and concurrent users. Web hosts like Winhost do a solid job with SQL Server hosting (and it's not pricey, either). I host my own site with them, and they're fantastic. If you want details or a walk-through on moving Access online, check out my course on migrating to SQL Server.
Another quick win: if you hate how Access query windows never remember your column widths or layout, I get it. But don't blame resizing for query weirdness - lost columns or prompts for missing field names usually mean you changed the query logic or renamed something in your table, not just moved the window around. Save yourself the headache and use forms in Datasheet View if you crave a persistent, user-friendly layout. Queries handle the data logic, forms are for the pretty face. And as a rule, your users should never see raw queries or tables anyway - a locked-down form experience is always better.
What about connecting multiple users to your database backend? If you're still having users open the SAME front end file from a network share, congratulations - you've entered Access Danger Zone. This is a recipe for locking issues and corruption. Proper setup: one shared backend, local front ends for every user. Yes, this setup is worth the few extra clicks it takes to update front ends, and you'll thank yourself the first time office-wide corruption doesn't take down your database.
If you've ever had to dig for a field name in a messy database, exporting all your VBA code and object definitions as text can be a lifesaver. There's no giant "Print All Code" button, but you can automate exporting modules, forms, and reports using VBA's SaveAsText command. It's perfect for code search, backups, and even sending object code via email if you're dealing with overzealous firewalls. If inconsistencies in field names are giving you a headache, that's a screaming sign it's time to standardize - future you will be very grateful.
Now, a few quick-fire fix-its: If you run an append query, then delete the new record and try again, suddenly Access wants a parameter - most likely, you've renamed a field or the query's source changed. Pop open Design View and check every reference - usually it's just a typo. If you're getting exactly "99" records instead of all, even when you set "Top" to "All," you probably have a lingering TOP clause, a filter, or an aggregate hiding somewhere in your chain of queries or forms - hunt through each data source until you find the culprit.
Want a query filter field to be optional? Let blank text boxes show all records instead of filtering? Use a wildcard in the criteria. By default, if the form field is blank, feed an asterisk (*) to your query. This way, you show everything until the user adds a filter. Makes for a much friendlier end user experience - nobody likes being forced to type something just to see their records.
Thinking Access is old? I get that comment all the time, but here's the truth: Access is battle-tested, fast, easy to develop with, and actively maintained. Pair it with SQL Server and you have a full-blown modern client-server solution on the desktop. If someone says Access isn't modern, they've probably never really built anything serious with it. Don't let the naysayers talk you out of a great tool just because it's got some years under its belt.
Here are a few more odds and ends: If Windows updates and every installer are suddenly failing, don't waste days poking through the registry. Back up and reinstall Windows - it's usually faster in the long run. Wondering how to automate relinking tables or efficiently update user front ends? There are great tools like J Street Access Relinker, or you can handle it yourself in VBA (I cover both). If you're a coder at heart, little quality-of-life utilities - like a custom VBA function to output multiple new lines at once - make everyday programming much smoother. Sometimes, it's these small touches that add the most polish to a professional database.
And yes, if you want to branch out into VBA for Word, Excel, or even Visual Studio programming, there are free beginner resources available (on my site and on YouTube), and a bunch of courses for Access, Excel, and more. If you enjoy nerding out, check out the next Access Day event coming up, or stop by my website for more free goodies, templates, or even some stylish merch for the Access enthusiast who has everything.
Bottom line: Use Echo with care, wildcards make optional query parameters a breeze, always use local front ends, and don't be afraid to export (and wrangle) your code for cleaner development. Post any questions below and let me know what you want to see answered next!
That's a wrap. You can always watch the video above for more details and the full walk-through - happy coding!
Tired of waiting for a never-ending Access loop to finish, just so you can realize you needed to hit cancel three minutes ago? Let's talk about a simple way to let your users abort a running process with the keyboard - no more clunky checkboxes, no frantic clicking, and (most importantly) no forced shutdowns required. The Escape key can be your new "panic button." Here's how and why you should set this up in your own databases.
When you create long-running operations - like sending out 10,000 emails in a batch - your users might suddenly realize they need to stop the process. If you don't give them a way to abort gracefully, their options are ugly: force-quit Access, cross their fingers, or just stare in silent dread. Historically, maybe you added a hidden checkbox or "abort" button, but those solutions aren't very friendly (especially to keyboard-focused users or anyone with a penchant for hitting Escape in emergencies). Let's teach your database to listen to the Escape key and stop those runaway loops on command.
Let's start with the basic approach: tying an on-form "Cancel" button to the keyboard. Access forms have a handy built-in feature: any command button set to Cancel = Yes automatically responds to the Escape key. So, if you stick a "Cancel" button on your form and connect it to your abort logic, your users can smash Escape and halt the process without fumbling for the mouse. Just make sure you wire up your loop so it checks regularly for an abort request.
But here's a power tip: don't forget about DoEvents. This little command sprinkled inside your loop is what lets Access recognize outside actions - like button clicks or keys being pressed. Without DoEvents, your process hogs the show and ignores everything else, giving the illusion that Access has frozen. So, always include DoEvents (often inside a status update function) during each loop iteration.
Now, for those who want an even cleaner keyboard solution, you can skip the "Cancel" button entirely and work directly with keyboard events. Here's how:
1. Open your form's properties and set Key Preview to Yes. This tells Access your form wants first dibs on all keyboard activity, regardless of which control is active.
2. In the form's On Key Down event, check for the Escape key by testing If KeyCode = vbKeyEscape.
3. When Escape is pressed, set your abort variable (maybe Abort = True) and swallow the key (KeyCode = 0). For bonus feedback, update the status display so users know you heard them.
This approach is more "global" to the form, so you don't need a visible user control at all. As long as your loop keeps checking for Abort = True (don't forget that DoEvents!), users can bail out instantly, just by hitting Escape.
Keep in mind, the responsiveness depends on how often you check for that abort signal. If your loop has a long delay (for example, sleeping a full second between iterations), the cancel might feel sluggish. For faster response, either shorten the sleep interval or check for aborts in smaller increments inside your main loop.
What about taking this further, so you can trap Escape key presses throughout your entire database, not just on a single form? That's possible too with a tiny bit more advanced VBA, and I cover that in my member-exclusive extended tutorials. (Not a member? Time to consider an upgrade… there's a code vault packed full of goodies over on my website!)
Bottom line: making the Escape key your abort switch gives your users a fast, intuitive way to kill a stuck process - and it makes your applications feel a lot more professional and user-friendly. I'm a keyboard person myself, so this kind of improvement just feels natural.
If you want the detailed walk-through, check out the video above. Have questions, or want to share your own favorite abort methods? Let me know in the comments!
