Fixing Automation Error Catastrophic Failure in Microsoft Access

There are few things in the world of Microsoft Access that inspire as much dread as opening your database and seeing the message "Automation Error: Catastrophic Failure." Sounds pretty dramatic, right? If you've ever stared down this monster of an error, you know it feels like Access is telling you your database is toast, you're doomed, and maybe you should start considering a new career. But take a breath - this error usually isn't as terrifying as it sounds.

Before you start mourning the loss of your carefully built database, let's get something straight: despite the name, catastrophic failure almost never means all is lost. Most of the time, something relatively minor tripped up Access, and there are a handful of straightforward troubleshooting steps you can use to get things back on track.

First things first: don't panic. I know, that's about as useful as telling someone to calm down as their hair is on fire, but trust me. This error is usually just Access throwing its hands in the air and confessing, "I don't know what happened, so here's the scariest message I've got." Most of the time, it doesn't mean your code is bad or your whole database is corrupted beyond repair. The actual problem tends to be an issue with your compiled VBA code, not the database itself.

Here's what's going on under the hood. When you write VBA in Access, the application compiles your code into an internal format known as "pcode" (pseudo code). This makes execution faster. But if this compiled copy gets corrupted - say, after a crash, a bad update, or even importing dodgy objects from somewhere else - you can get strange errors like "catastrophic failure." Sometimes it's as simple as Access waking up on the wrong side of the bed. (I've been there myself more times than I care to admit.)

So what do you do when this beast shows up? Start by making a backup of your database - yes, even if you suspect it's already broken. Don't experiment on your only copy. Save the current version somewhere safe before you do anything else. Then, shut down Access completely. Open your task manager and make sure there aren't any stray msaccess.exe processes hanging out in the background. If you see any, kill them. Access is notorious for leaving little pieces of itself running after a crash.

If that doesn't fix the issue, give Windows a reboot for good measure. I know, "turn it off and on again" is a tech cliché, but you'd be amazed how many weird problems it fixes - shared DLLs between Office apps, memory leaks, or Office just acting grumpy because you left PowerPoint open for four days straight.

Still getting the error? Next move: compact and repair your database. This is kind of the classic Access tune-up. If your database structure has gotten a bit tangled, compact and repair can often untangle things enough to get you running again.

If the problem persists, it's time to get serious with the "decompile" command. What's decompiling? In short, it tells Access to dump the pcode (that internal compiled VBA stuff) and rebuild it fresh from your original source code. Don't worry, your actual VBA code is safe - just that compiled layer gets trashed and recreated. This simple step fixes catastrophic failure errors about 90 percent of the time, in my experience. Check out the embedded video above for details on how to run a decompile if you haven't done it before.

Once you're back in business, be sure to make a new backup of your now-functional database. (Seriously - backups are not optional!) But if you're still seeing catastrophic failure after all that, it's time to look deeper. Head to the VBA editor, go to Tools > References, and see if anything is marked as "Missing." A broken reference can cause all kinds of bizarre Access behavior. If you spot a missing reference, resolve it by either fixing the link or unchecking it if it's not needed. Don't hesitate to check out my video on reference problems if you need a hand here.

Sometimes the problem is tied to a specific form or report. If the error only pops up when opening one object, odds are that object is corrupt. Try deleting it and importing a clean copy from a backup, if you have one. And watch out for ActiveX controls - these little troublemakers are notorious for breaking after Office or Windows updates. If you're still using those, well, you've been warned.

If nothing so far works, you might have an issue with the database file itself. Try creating a blank new Access file and import your objects one at a time from the troubled database. Very often, this will leave behind whatever corruption haunted the old file. Import each object individually - if one refuses, you just found your culprit.

Still pulling your hair out? At this point, it's wise to run through a full troubleshooting checklist. Sometimes antivirus software or third-party tools can get in the way, so check those as well. And as always, reach out in the comments or forums if you get stuck. Chances are if you're facing a weird Access problem, someone else has too, and more than likely, we can figure it out together.

The big lesson? That terrifying error message is usually not the end of the world. Start with backups, try the basics - compact and repair, decompile, check references, and swap out suspect forms or controls. Most catastrophic failure errors are recoverable. With a bit of patience (and a good backup routine), you'll be back to work in no time.

If you want the full demo, including step-by-step walkthroughs for decompiling and more troubleshooting, check out the embedded video above.

Live long and prosper,
RR

Microsoft Access SQL Server Online: Set Up Your WinHost Server

Getting your Microsoft Access data online isn't rocket science, and it definitely doesn't have to break the bank. There's a neat, straightforward way to host your Access back-end on a SQL Server in the cloud. Whether you want to support remote employees, connect multiple offices, or just get to your data while traveling, moving your Access backend online makes a whole lot of sense.

The good news is, modern SQL Server hosting is incredibly affordable. You can get started for about the price of a large coffee per month, especially if you jump on the basic plans at places like Winhost. I've tried several hosts (and I've got the scars to prove it), but I keep coming back to Winhost - they're reliable, they know what they're doing, and their support team actually replies to emails as if they're written by real humans.

So let's walk through how to get set up. You don't need to be an IT wizard, just have some basic computer skills and a healthy distrust for GoDaddy (I speak from experience).

The process starts with heading over to Winhost.com. If you want to put your Access data online, you'll need a hosting plan - nothing fancy, just sufficient space to hold your database and support some web traffic. Even their basic plan offers plenty for an Access SQL Server setup: a few gigs of web space, more bandwidth than you'll probably ever use, and a SQL Server database that's big enough for pretty much any non-enterprise project.

If you don't already own a domain name, Winhost can grab one for you. But if, like me, you hoard domain names elsewhere (I still have some from the dot-com boom!), just point your existing domain's nameservers to Winhost. It's as simple as popping their DNS addresses into your registrar's control panel, clicking save, and waiting for the Internet to catch up. Don't panic if it takes a few hours for the new address to kick in - sometimes it's instant, sometimes it's the digital equivalent of watching paint dry.

During signup, they'll ask for the usual billing stuff and offer a couple upsells like nightly backups or basic site protection. If this is for a real business, I'd spring for the backups. But for learning or demo purposes, you can save your cash.

Once you've signed up, check your email. You'll get the keys to your new kingdom - login details for your hosting control panel, FTP access, database credentials, and all that jazz. Do yourself a favor and copy these to a safe place. I always park them in Notepad while I'm setting things up (yes, Notepad, because who needs another complicated password manager debacle?).

If you're linking a domain from another provider, make sure to update its nameservers to the ones provided by Winhost. There's a short lesson in Internet plumbing here: nameservers are basically giant phone books that tell the world's browsers where to find your site. Point them to Winhost, and you're in business.

With the web space and domain in place, let's focus on SQL Server. In your Winhost control panel, there's an option called MS SQL Manager (don't get sidetracked by MySQL - it's not what we want here). Click it, create a new database, and give it a name you'll remember. Stick with the latest version unless you've got some very old applications to support.

Here's a pro tip that most people miss: use a unique password for your database and another for your web hosting account. Never recycle passwords between the two, especially if you're letting others access the Access front end. Security first - nobody wants their database hijacked by a bored teenager in another country.

After the database is provisioned, jot down (or copy and paste) the connection information. That connection string is gold; it tells Access or your website how to hook up to your SQL Server backend. Plug in your new database password (replace those asterisks) and stash it somewhere safe. You'll need this connection string when linking tables from your Access front end or connecting from a web application.

If SSL matters to you (which it should, unless you enjoy sending your data in plain text across the wilds of the Internet), order a basic SSL certificate from Winhost. It's usually just a few bucks, and it keeps your stuff encrypted and safe from prying eyes. At the very least, treat yourself to HTTPS before you go live.

That's about it for the setup. Your hosting is ready, your database exists in the cloud, and you've got the credentials needed to start building, migrating, and connecting Access to SQL Server from anywhere you have Internet. If you're looking to take it further - migrating your Access tables, securing user access, optimizing performance, or maybe even building a simple browser-based app - that's all covered in the full video.

So, if you're ready to modernize your Access database and set it free from the shackles of a dusty old file server, now you know how to start. The video embedded above has the blow-by-blow walk-through if you want to see each step in action.

Live long and prosper,
RR

How to Track How Long a Form Was Open in Microsoft Access Without a Timer Event

Ever wondered how much time you spend actually working in a particular part of your Access database? Sure, it might seem trivial, but tracking how long you spend on certain tasks - like following up on customer lists or pushing through your custom workflows - can be a great way to spot bottlenecks, gamify your routine, or just satisfy your curiosity. What's even better: you don't need a distracting timer ticking away in the corner of your screen to do it.

Let's talk about a nice, lightweight way to track the open time of any Access form, without resorting to Timer events. Timer events are handy but can be distracting, sometimes steal the focus from other things, and in general, feel a bit overkill for something as simple as tracking how long something was open. I personally prefer to avoid timers unless I really have to. Here's a practical approach that leverages a dash of VBA and a couple of events, and you'll barely even notice it's working - until you see the results.

The concept is simple. When you open the form you want to track, you just save the current time - store it somewhere that sticks around for the duration of your session. For this, I love using TempVars in Access. If you're not already using them, TempVars are little variables that persist globally in your database until you either remove them or close the database. That makes them perfect for things like this, especially since they'll survive most errors that might crop up while you're testing or making tweaks.

When the form opens (you can use either the On Open or On Load event), set a TempVar - let's call it FormOpenTime - to the current time using the Now function. If you're the kind who likes instant feedback, you might even have a little status box or message pop up to tell you when the tracking started (I use a custom status box for this; it's just more fun than the usual MessageBox spam). If you'd rather not see the full timestamp, Format will give you just the time in an easy-to-read way.

That's half the battle. Now, when the form closes (triggered by the On Close event), it's time to take the difference: subtract the open time (saved in the TempVar) from the current time. The DateDiff function is your best friend here. Calculate the number of minutes (remember, "n" is for minutes in Access - don't ask why, just go with it), and you'll know exactly how long the form was open.

While you're at it, you might as well add a little polish. If it was less than a minute, show "less than one minute." If it's exactly one, say "1 minute." Otherwise, just display the actual number - bonus points for pluralizing "minute" properly. Trust me, your users (and your future self) appreciate those little niceties.

One more thing: after you've calculated the duration, it's good practice to remove the TempVar you set. It isn't strictly necessary - it'll hang around until you close the database - but if you build habits like this you'll have a much cleaner environment, especially if you work with lots of temporary data points.

This approach keeps things super lightweight. There's no timer constantly updating, no forms flickering, nothing chewing up resources in the background. You just note the start time, do your work, and when you close out, Access does a little math and spits out your total time for the session. It's exactly what you need for daily checklists, customer service review, account reconciliation, or any repetitive task you want to analyze or improve.

One thing to note: what I've described here is hard-coded for a single form. If you want to track multiple forms in your database without duplicating code everywhere, you can kick this up a notch and build a reusable framework - a big win for bigger databases or anyone who really likes stats. In the video above, you can see the full implementation details and how to expand this for all your forms, plus tips on logging the data over time and viewing reporting by user, form, or whatever metric you need.

Give it a try - the VBA is minimal, the logic is easy to follow, and you might be surprised at how informative this little tweak can be. Check out the embedded video above for the full step-by-step walkthrough and live demonstration. Happy tracking!

Live long and prosper,
RR

Microsoft Access & SQL Server Online Database: Work With Your Data From Anywhere

Ever found yourself frustrated that your Access database is chained to one office, or stuck on a dusty server nobody wants to reboot? You're not alone. There's a world of difference between having your database on a single local network and making it available from anywhere - whether your team is remote, scattered across offices, or you just want to squeeze in some database work while waiting for a flight at the airport. Today we're diving into how to move your Microsoft Access database online using SQL Server. It opens up a whole new level of accessibility… and headache prevention.

Let's get straight to the point. If you want folks in multiple places to use the same data, putting your Access backend into SQL Server online is the answer. Access becomes the clever user interface, and SQL Server does the heavy lifting on the backend. Not only does this allow people to log in from pretty much anywhere on the planet (as long as there's an internet connection), but it also means you're not limited to Windows PCs. Sure, the Access runtime is free for Windows, but once your data is in SQL Server, Excel VBA, Android apps, Macs - you name it - can pull in that data too.

The catch? There's always a catch. Big tables can take time to download if you ask Access to pull everything at once. If you're running reports on a table with, say, 50,000 customers, don't expect it to be lightning fast unless you plan ahead. That's where pass-through queries save your bacon. Instead of transferring every last record, you let SQL Server do the heavy sifting and just send down what's needed. It's a bit of a redesign if you're upgrading an old Access database, but the payoff is real. You'll have to rethink those old reports and queries - trust me, it's worth it.

If you're worried about security and safety, hosting online is actually more locked-down than most in-house setups. With a split Access database, everyone who messes with the backend share has full access (and therefore full opportunity to break things badly). Online SQL Server? People need credentials, and you can add real access controls. Pro tip: keep those passwords secret and safe. You don't want to be the reason someone across the world wipes out your customer table.

Another benefit: backups and reliability. If your office building spontaneously combusts (hey, stranger things have happened), your data is safely stored offsite. These host providers usually offer regular backups for a few bucks a month - absolutely get that in place. And if your internet drops, just fire up your phone's hotspot or use a backup connection. It's actually easier to work around a lost internet connection than to recover from a dead local server.

As for management, let the hosting pros sweat the updates and patches. I learned this the hard way years back when I had to manage my own SQL Server and ended up on the wrong side of a Pentagon denial of service attack. Yeah, you do NOT want to be the sysadmin who forgets a patch. Nowadays, let someone else handle the security while you focus on building good databases.

Oh, and user limits? Forget the 10 or 20-user constraints on a classic Access backend. SQL Server can handle hundreds of users at once if you've got the bandwidth for it. The only real limiter now is your internet speed, not the number of people banging on the tables.

A caveat: attachments, multi-valued fields, and hyperlinks don't translate well to SQL Server. But honestly, you shouldn't be storing attachments in Access anyway. That's just asking for corruption.

What do you need to get rolling? Simple: a single licensed copy of Microsoft Access (the full version for the developer), Windows-based SQL Server hosting (I highly recommend Winhost.com - after experimenting with others, trust me on this one), and if you want web access, a page editor and maybe a crash course in ASP.

Good news for your end users: they don't need to buy Access. The free Access Runtime edition does the trick for them. They just install it, and they're in. Only people designing reports or tweaking the database itself need the full Access install. For everyone else, it's free and easy. And if you want to keep folks away from the actual Access client, you can always build a simple web portal - they hop into their browser and go.

To sum it up: shifting your Access backend to SQL Server online means remote access, better security, real backups, and less IT stress. It takes a bit of setup and a change in how you build your queries, but once you're there, you wonder why you ever suffered with a shared Access file buried on some old server.

If you want to see the full step-by-step, including setting up your Winhost account, installing SQL Server Management Studio, uploading your database, and all the fun configuration bits, check out the embedded video. I go through it from start to finish so you won't miss a thing.

Live long and prosper,
RR

Why Is Microsoft Access Not Available For Mac?

Microsoft Access has been around on Windows for what feels like forever, and yet if you're a Mac user, you're still out of luck when it comes to a native version. A lot of people wonder why Access never made its way over to macOS, especially when Word, Excel, and PowerPoint have happily lived on both platforms for years. Considering how many businesses and individuals get locked into the Windows ecosystem because of Access, it's a pretty reasonable question.

This isn't just about checking one more box on the Microsoft Office for Mac installer. Access is a different beast entirely compared to Word or Excel. While Word is just a really powerful word processor and Excel is the champion of spreadsheets, Access is a full-blown database development platform under the hood. If you know Access, you know it's got tables, queries, forms, reports, VBA code, macros, and a ton of little moving parts living together in every database file. It's not exactly your average Office app.

The biggest hurdle comes down to technology. Access was built from the ground up around Windows plumbing - stuff like the Jet and Ace database engines, COM automation, ActiveX, VBA integration, the whole Windows API, and a pile of Windows-only drivers and libraries. Microsoft can port Word and Excel to Mac because those apps don't depend as heavily on Windows-only tech. Access, on the other hand, would need a massive rewrite from scratch. They can't just hit "recompile" and get a working Mac version, not even close.

Meanwhile, there's a business side here too. Access thrived in the Windows business environment. By the time Macs started showing up in large numbers at work, there were already solid contenders on the Mac side, like FileMaker Pro, which Apple eventually bought. So if you're Microsoft, you do the math: huge cost to rebuild, comparatively tiny Mac market of diehard Access users, and a world where most businesses already run Windows when they need Access. It's just not an attractive investment.

Some folks will tell you Microsoft kept Access Windows-only on purpose, just to keep businesses on Windows PCs. Let's be honest, that probably didn't hurt, but the technical and market realities were really what made the difference. If it was low-hanging fruit, we'd have it already.

Fast forward to today, and the story gets even more clear. Microsoft is pouring more effort into cloud-based stuff like Power Apps, Azure, and Dataverse. These platforms work everywhere, Mac or PC. Instead of spending a fortune rewriting Access for Mac, they focus on tools that run in any browser or on any device. Access for Windows is still alive and well (new features are even coming out), but asking for a native Mac version at this point is a long shot.

So what are your options if you're a Mac user who needs Access right now? Virtualization is the trick. Tools like Parallels Desktop and VMware Fusion let you run a full Windows environment right alongside macOS, and by all accounts from the Access community, they work great for running Access. You'll need a separate Windows license and a copy of Access, but it's the best way to get the full experience. Remote Desktop into another Windows machine is another common workaround, especially if you have a work PC sitting somewhere or a cloud-hosted Windows box to connect to from your Mac.

But if you're holding out hope for a real, native Mac version of Access? At this point, don't. It's just not likely to happen. The technical barriers are high, the business case is weak, and honestly, there are solid workarounds these days for people who truly need Access on a Mac.

If you want to see how all this looks in action - plus a few more tips for running Access on a Mac - check out the embedded video for the full walkthrough and discussion.

Live long and prosper,
RR

Celebrate America's 250th Independence Day With Fun Facts and Humor in 2026

It's not every day you get to celebrate a quarter of a millennium of freedom, but that's exactly what's happening in 2026. America's hitting the big 2-5-0, and if you're a fan of history, fireworks, or just looking for a good excuse for a backyard barbecue, this is a milestone worth marking. Sure, every Independence Day comes with its own traditions, but let's face it, you don't get to throw a semi-quincentennial party every year (try saying that after your second root beer float).

Let's start with that word - semi-quincentennial. It might sound like something a Roman emperor shouted at you in Latin class, but it actually just means 250 years. "Semi" is half, "quin" is five, and "centennial" is 100. So if you ever find yourself at a trivia night or you want to impress your friends at the grill, now you can explain why we aren't just calling it "America's Big Birthday Bash."

Think about where we've come from since 1776. In 250 years, America has fought wars, survived a depression or two, landed on the moon, and let's not forget - brought air conditioning to the masses. If there's one invention we can all be especially grateful for each Fourth of July, it's definitely that. There's also the little device you're probably reading this on right now - one that can access the entirety of human knowledge, but let's be honest, mostly gets used to watch silly videos and debate with strangers online. Ah, progress.

What's always worth celebrating, though, are the ideals that started it all: liberty, self-government, and the freedom to speak your mind (even if what you have to say is just a hot take about potato salad). After all these years, those values are still as important - and sometimes as controversial - as ever.

If you're like me, you might be tempted to recycle a few jokes from last year's celebration. Why waste a perfectly good one-liner about fireworks, loud Labradors, or your British friends who still haven't quite forgiven us for 1776? Speaking of which, if you do have British pals watching, be kind to them - it's a tough week for their pride and their tea supply.

But let's talk safety and etiquette for a second. Fireworks are as American as apple pie and questionable fashion choices, but I can't encourage you enough to be respectful. Military vets, pets, and parents of young kids in your neighborhood will all thank you for saving the artillery show for reasonable hours. Here in my part of Florida, the rules are pretty clear: light 'em up on the Fourth, not on the Third (or at three in the morning unless you want your popularity to drop faster than a dud sparkler). Remember, there's always that guy who can't wait to celebrate early - and the only thing he's blowing up is his reputation as the neighborhood nuisance.

Of course, you also need to make sure you're buying legit fireworks. Just because you found a "boom stick" on a card table in a gas station parking lot doesn't mean it's a wise investment. Shop smart, treat your fingers kindly, and don't forget to leave out cookies and milk for Captain America (because why should Santa get all the snacks?). And maybe give a nod to Will Smith and Jeff Goldblum while you're at it - after all, they did save us from the aliens, right?

At the end of the day, America's 250th Independence Day is a celebration of freedom - and of those who fought to secure it, long before any of us were around. We may not always agree with everything happening in the country, but the fact that we're free to voice those opinions is worth a party all on its own.

So enjoy your fireworks, your hot dogs, and your family time. Be safe, be considerate, and most importantly, have a great Fourth - no matter what side of the pond your ancestors came from.

And if you want some extra tips, fun facts, or just want to catch a few recycled jokes, check out the embedded video for the full rundown.

Live long and prosper,
RR

Power Apps for Microsoft Access and SQL Server: Build a Mobile Front End

Ever wish you could pull up your trusty Microsoft Access database on your phone without having to rebuild everything from scratch? That's a pretty common request, and let's be honest, nobody wants to reinvent the wheel (or their Access app) just to get some mobile action. Good news: you can actually build a simple mobile front end using Microsoft Power Apps with your existing Access database. The trick is to let SQL Server do the heavy lifting in the background.

As much as folks sometimes panic about "replacing" Access, that's absolutely not what's happening here. Access stays right where it is as your desktop front end. We're just storing your data in SQL Server so Power Apps can play with it too. That way, you get to keep the database you know and love, but your data is accessible from just about anywhere - your phone, tablet, even your website (if you want to go that far). When you're done, you'll be able to whip out your phone, launch a Power App, and see your familiar data, while everything on your desktop keeps working just as it always did.

So, why move your data to SQL Server in the first place? Well, if all you really want is remote access to your same old Access database, you could just use Remote Desktop or a hosted Windows solution. Shoot, most of the time when I'm traveling, I just leave my computer on at the office and remote in. It works, but it's not for everyone - maybe you don't want to leave your computer running nonstop, or perhaps you need something that feels more like a true mobile app.

When you need more flexibility, moving your tables up to SQL Server becomes the clear winner. SQL Server acts as a reliable, central store for your data. Not only can Access connect to it seamlessly (if you relink your tables), but so can other applications - including Power Apps, reporting systems, and custom web apps you might build in the future. One database, any number of front ends, and your users get to work however they like best.

You've also got options like SharePoint or Microsoft's Dataverse (especially if you're deep into the Power Platform or Dynamics 365). I still lean towards SQL Server, simply because it's industry standard, rock solid, and works with pretty much everything.

Now, let's get to the fun part - building the Power App. Here's the basic plan:

1. First, make sure your Access data lives in SQL Server. If you need help with that, I've got free lessons that walk you through setting up an account (Winhost is great), creating your database, moving your tables, and relinking everything back to Access so it still behaves just like always. Get that done first; it's painless and the foundation for everything else.

2. With your data online, hop over to make.powerapps.com. Sign in with your Microsoft account, hit "Create," and choose "Canvas app from blank." Pick the "Phone" layout (unless you want to get fancy with responsive apps, which is a whole separate adventure). This approach feels very similar to Access's form designer - you've got a blank canvas, you put controls wherever you want, and you get to design exactly the UI you need.

3. Next, get your SQL Server data connected. Add a new data source and search for SQL Server. Heads up: SQL Server is a premium connector, so you'll need a Power Apps license (the price changes, but plan on about $20 a month at the time of writing). There's a free trial and a developer plan too if you just want to get your feet wet.

4. Enter your SQL Server connection info (from your host), tell it which tables or views to use, and voila - your Power App now has access to your Access data, via SQL Server, right on your phone. Honestly, the hardest part of this is just getting those connection strings right. Once it's connected, adding forms and fields is easy, and feels like second nature if you've ever built Access forms.

Quick warning: Power Apps is designed for internal business apps, not public websites. Every user needs a Microsoft account and appropriate permissions. If you wanted a public-facing interface, you'd probably want a custom web app instead. But for your employees or trusted users, Power Apps is excellent.

Third-party tools like Retool and Appsmith exist too, and I've seen people use them to great effect, but Power Apps is a no-brainer if your world already revolves around Microsoft 365.

You don't need to be a master programmer here. Power Apps handles a ton of the heavy lifting for you - drag and drop, link to your tables, set up some logic, and you've got a perfectly serviceable mobile view of your back-office data in an afternoon.

The bottom line: Migrating your Access tables to SQL Server doesn't mean giving up Access. You're gaining the ability to connect to all kinds of front ends. Power Apps is a great way to get started building lightweight mobile (and web) applications without leaving the Microsoft ecosystem or losing all your work in Access.

If you want to see me go through the process step by step, the video below walks you through the entire process, shows the screens, and gives you a good look at the pitfalls and little tips I've picked up from experimenting with Power Apps and Access integrations. Check it out if you want to see the whole thing in action.

Live long and prosper,
RR