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!
Ready to wrangle some data directly in SQL Server? Today, we're diving into how to enter and edit records right in your tables using SQL Server Management Studio (SSMS). You'll see how to add new records, handle those infamous required fields, make sense of identity IDs (autonumbers), and even import sample data from Access - using Excel as your trusty go-between. All of this is super handy for developers and serious Access users who want a real-world set of data to play with as we build out our queries.
If you've ever made tables in Access and fiddled with data directly in them, you already get the vibe. While your users will (hopefully) never touch the backend tables, as a developer you sometimes need to sneak in behind the scenes - add a test record, make an edit, or just seed a few rows so things aren't completely empty. Being able to enter data straight into SQL Server tables through SSMS lets you do all this quickly.
The most straightforward way to enter data in SSMS is to right-click your table in the Object Explorer and choose "Edit Top 200 Rows." Why 200? Because Microsoft picked a number, and that's what you get. This opens a grid very reminiscent of Access datasheet view, putting you in edit mode so you can start typing directly into cells.
Here's how it works: Columns that are locked (like an auto-numbered primary key) can't be edited, but move over to fields like "FirstName" or "LastName" and type away. One thing to notice - unlike Access, where the autonumber appears as soon as you start typing, SQL Server assigns its identity ID only after you save the record (by moving off the row). At first this feels a little weird, but you get used to it - and it's important to understand if you're coming from Access, because it can affect how you write your code, especially if you're inserting related child records that need that ID right away.
While you're editing a row, you'll see a little pencil icon appear (just like in Access), which means the record is "dirty" and hasn't been saved yet. There's also a red exclamation point - don't panic, it's just SSMS's way of saying changes haven't been written yet. If you try to leave a required field blank (like "LastName"), you'll get an error. SQL Server's error messages are rarely warm and fuzzy, so actually read what it says. Fill in your missing data, and move off the row - the warning goes away, data is saved, and your new identity ID is assigned.
Sometimes, you might see a message that the record was saved, but a problem occurred while retrieving the data back. Relax - your record has been saved, SSMS just got confused. Just close and reopen the grid, and your data (and shiny new ID) will be there.
When entering certain types of data, like percentages, you'll want to stick to the standards most Access developers use: enter 0.1 for 10%, 0.5 for 50%, and so on. This keeps your calculations easy and consistent, and generally saves you from having to divide or multiply by 100 in your queries later. And yes - things like formatting (especially for dates) might look goofy in SSMS. You might see a big ugly datetime with seconds and milliseconds, but that's just how SQL Server wants to show it. Don't sweat it - you'll handle the pretty formatting in Access or in your reports later.
For Boolean fields, even though SSMS will display "True" and "False," you should get in the habit of entering 1 for true and 0 for false. SQL Server likes it that way, and you'll avoid those oddball issues that pop up when you try to insert other values. Access is more forgiving; SQL Server likes to keep things black and white - or, well, ones and zeros.
Let's talk about importing data. If you have a set of sample data in Access (like from my TechHelp Free Template), an easy way to bring it into SQL Server is: copy it to Excel, tidy it up, and then paste it into your SSMS table grid. This works nicely because you can rearrange, add, or delete columns in Excel so everything lines up perfectly with your SQL table's structure.
For example, if you have extra columns in your Access export (like "Phone" when your SQL table doesn't have a phone field), just delete them in Excel. Want to skip pasting IDs so SQL can assign them? Delete those values as well. Make sure your columns match the order of your SQL table - don't be afraid to cut and insert columns as needed to make everything fit. If your numbers (like credit limits) copied over as dollar amounts, remove the pesky "$" - SQL Server does not like those. Format dates as plain short dates. Remove the header row, copy your prepped data, click in the first row in SSMS, and paste. Done! If you get errors, double-check your formatting - almost always, it's a stray symbol, wrong column order, or a non-matching data type.
Keep in mind, this method is for sample or test data and not for production loads. It's the perfect way to get a handful of records into your table so you have something to work with when writing queries, forms, or reports. Trust me, testing queries on empty tables is no fun.
And there you have it! You now know how to enter and edit data right in your SQL Server tables using SSMS, manage identity IDs, and import sample data from Access via Excel. This hands-on knowledge makes it much easier to develop, test, and troubleshoot as you build your application.
If you need a deeper walk-through (or just want to see it in action), check out the video above. Parts 2 and 3 of the course are waiting for you on my site, by the way - and don't forget, Silver Members and up get a free class every month!
Recent events have forced me to rethink a couple of long-held assumptions, and anyone who knows me knows I don't do that lightly. Not about parties or personalities, but about power itself, how it's structured, and how easily it can be stretched beyond what feels healthy for a democracy.
First is the power of the presidency. Over time, the office of President of the United States has accumulated an enormous amount of unilateral authority. Executive orders, emergency powers, tariff controls, agency directives. All tools that were meant to be scalpels, not sledgehammers. Tools that were often intended for limited or urgent use now feel like levers that can reshape massive portions of government with the stroke of a pen. That concentration of power makes me uncomfortable, regardless of who holds the office.
In Starfleet, even a captain commanding a starship doesn't operate without guardrails. There are regulations, oversight, and the possibility of being relieved of command if judgment fails. Absolute authority sounds efficient, right up until it isn't.
This isn't about Republicans or Democrats. It isn't about Trump, Biden, or whoever comes next. The concern is structural. One individual should not be able to make sweeping economic decisions, reorganize federal agencies, or redirect national policy without meaningful legislative oversight. Especially in times of peace. Decisions involving money, trade, and taxation should run through Congress. That's where the constitutional authority over the purse was designed to live. Invoking emergency or war-adjacent powers when there is no declared war blurs lines that were originally put in place as guardrails, not suggestions.
Government departments should be independent of whichever political party is in power. I want the best doctors in charge of the CDC. I want career educators shaping national education policy. I want experienced economists guiding commerce and trade decisions. I want seasoned investigators overseeing federal law enforcement agencies like the FBI. I want climate scientists directing environmental policy, engineers and urban planners leading infrastructure and transportation, energy specialists managing the power grid, banking and securities experts regulating financial markets, and scientists running federal research institutions.
These roles affect public safety, financial stability, and long-term national planning. They require institutional knowledge and technical expertise that takes years, sometimes decades, to develop, and they shouldn't turn over simply because a new administration wants ideological alignment at the top. I don't want politicians playing musical chairs with positions that require a lifetime of expertise.
If the Enterprise is in a medical crisis, you want Dr. Crusher in Sickbay, not someone appointed just because they're politically loyal to Captain Picard. Competence matters more than allegiance when lives are on the line. When the warp core is destabilizing, you want Scotty running the diagnostics, not someone assigned to the engine room because he was buddies with Kirk at the Academy.
Leadership continuity in these areas matters. These positions shouldn't be subject to abrupt dismissal on the whim of a president, or the mood of a news cycle. If anything, appointments at that level should require broader legislative approval and oversight, ensuring that competence, not partisanship, is the primary qualification.
The second shift in my thinking involves states. For years, I've questioned whether state governments were still necessary in their traditional form. They originated in a very different era, when communication was slow, travel was difficult, and real-time updates meant waiting three weeks for a letter. Regional governance filled logistical gaps that no longer exist in the same way. But I've come to see value in a secondary layer of government.
Not necessarily states as we know them today, but some form of regional authority capable of acting as a counterbalance to federal overreach. When national power becomes too centralized, there needs to be an intermediate structure with the legal standing to push back, slow things down, or chart a different course. In other words, a pressure release valve.
I'm not convinced the historical state map is the best model going forward. Larger regional or metropolitan coalitions might make more practical sense. Think in terms of major population and economic zones rather than borders drawn centuries ago. But the principle remains important. Two meaningful levels of government create friction, and friction, in governance, is often a feature rather than a bug. It prevents abrupt, sweeping change driven by a single office. It forces negotiation. It distributes power. It slows bad decisions down long enough for cooler heads to prevail.
The Federation itself is layered this way. Starfleet answers to civilian leadership, member worlds retain autonomy, and major decisions require consensus. It's slower than unilateral command, but it prevents one office from steering the entire quadrant off course. Tolkien built an entire mythology around the corrupting nature of concentrated power. The One Ring didn't just grant authority, it eroded judgment. Systems need safeguards for the same reason Middle-earth did.
So where I've landed, at least for now, is this: The presidency is too powerful and should be more tightly constrained, particularly in domestic and economic matters. Congress should reclaim more authority over money, trade, and structural agency change. And some form of strong regional governance is necessary to keep federal power in check, even if that structure evolves beyond traditional states. None of this is about scoring political points. Abuse of power is a risk inherent to power itself, regardless of ideology, party, or country. Systems matter more than personalities.
And when systems concentrate too much authority in one place, history suggests it rarely ends well. It reminds me of Rush's 2112, where the Priests of the Temples of Syrinx govern every aspect of society under the reassuring promise: "We've taken care of everything." Concentrated authority always sounds efficient... especially to the people holding it.
If you have ever moved a database from Microsoft Access into SQL Server and thought, "Well, a number is a number, right?" ... yeah, not quite. Picking the wrong data type can quietly cause rounding issues, reporting errors, and weird date behavior that you might not notice until real data starts piling up. Today we are going to make sure that does not happen by choosing the right field types from the start.
As we continue building out our customer table, this is where database design starts to get real. Text fields are easy. Numbers, currency, and dates are where precision matters. The choices you make here affect storage, calculations, compatibility with Access, and long term data accuracy. So let’s walk through the field types you are most likely to use and how to pick the right ones without overthinking it.
Let’s start simple. Say you have a field like FamilySize. No decimals, no fractions, just whole people. This is where you use an int data type in SQL Server. If you are coming from Access, think of this as your Long Integer equivalent. Clean, efficient, and perfect for counts.
Now let’s say you want to store something like a discount rate or measurement value. That is where float comes in. Float is the SQL Server cousin of Access Double. It is designed for approximate numeric values, especially where fractional precision is not mission critical. Percentages, rates, scientific measurements, those are all fair game.
But here is where a lot of people get into trouble. Money.
If you are storing currency values like CreditLimit, do not use float. Ever. Float stores numbers as approximate binary fractions, which means rounding errors can creep in. One transaction might round up, another down, and after thousands of transactions you end up with phantom pennies floating around your database. Fun in movies. Not fun in accounting.
Instead, use decimal. Specifically, something like decimal(19,4).
That pair of numbers matters. The first number is precision, the total digits allowed. The second is scale, the digits to the right of the decimal point. So decimal(19,4) means you can store very large numbers with four digits after the decimal. This closely mirrors how Access stores currency and makes migrations much smoother.
You might notice SQL Server has a built in money type. Yes, it exists. Yes, it works. But decimal is still the better design choice. It is more predictable, more flexible, and avoids some rounding quirks that money can introduce in calculations. When in doubt, decimal wins.
Next up, dates. Access keeps this simple with a single Date/Time field. SQL Server gives you options. If you only need the date, use date. But if you are migrating from Access, chances are you have time values mixed in. That is where datetime2 comes in.
Datetime2 is the modern replacement for the older datetime type. It offers better precision and flexibility. You will often see it written like datetime2(0). That number controls fractional second precision. A zero means no milliseconds, just standard date and time down to the second, which is perfect for most business systems.
Let’s not forget Boolean values. In Access you have Yes/No fields. In SQL Server, that becomes a bit field. One or zero. True or false.
One interesting difference behind the scenes is that Access stores True as negative one, while SQL Server stores it as one. Functionally they mean the same thing, but it is something to keep in mind if you ever inspect raw values or write cross platform logic.
Once your fields are in place, SQL Server starts organizing things a little differently than Access. Tables live inside schemas, usually dbo by default. Keys, constraints, indexes, and triggers are all treated as separate database objects rather than hidden table properties.
This is actually a good thing.
For example, constraints enforce rules directly at the server level. Required fields, default values, uniqueness, referential integrity, they all live with the data itself. That means the rules apply whether the data comes from Access, an import, or a web app. No more relying on forms or VBA alone to keep data clean.
Indexes are another big one. Think of them as performance boosters. Your primary key creates one automatically, but adding indexes to frequently searched or joined fields can turn a slow database into a warp speed one overnight.
And yes, beginners often forget to index foreign keys. I have done it myself. You will know when it happens because everything suddenly feels like it is running through molasses.
The main takeaway here is simple. Data types are not just storage containers. They directly affect calculations, compatibility, performance, and long term reliability. Choosing the right ones early saves you from painful redesigns later.
If you want to see this all built step by step inside SQL Server, the full video walkthrough is embedded above. It is worth watching just to see how these choices play out in a real table design.
Every database project starts the same way. You sit down, crack your knuckles, and say, "All right, let’s build some tables." Seems simple enough. But here is the thing most beginners do not realize. The design decisions you make right at the start will either make your life easier... or come back to haunt you six months from now. Today we are laying the foundation properly by building a real customer table in SQL Server, and we are going to do it the right way from day one.
When you create a new table in SQL Server, you will notice right away that it feels familiar if you are coming from Microsoft Access. You define your fields, assign data types, and configure properties. Same general idea. But SQL Server gives you more flexibility and more responsibility. It assumes you know what you are doing, so it will not hold your hand the way Access sometimes does. That means we need to be intentional about every design choice.
Let’s start with the backbone of the table, the primary key. In a customer table, that is almost always going to be something like CustomerID. In Access you would use an autonumber. In SQL Server, the equivalent is an INT field with Identity enabled. You create the field as INT, then open the column properties and set Identity Specification to Yes. That tells SQL Server to auto generate the next value for each new record. Identity Seed and Increment usually stay at 1.
One very important point here. Setting Identity does not automatically make the field the primary key. That is a separate step. You still need to explicitly set the primary key using the toolbar button or right click menu. SQL Server will not remind you. Forgetting to set a primary key is one of the most common beginner mistakes, and it can cause headaches later when you start building relationships.
Once the ID is in place, we can start adding text fields like FirstName, LastName, and Email. This is where data types matter more than most people expect. SQL Server gives you several text options: CHAR, NCHAR, VARCHAR, and NVARCHAR. The difference comes down to fixed vs variable length and Unicode support.
Fixed length fields like CHAR always reserve the full space you define. If you set CHAR(50), SQL Server stores 50 characters even if the name is Bob. Variable length fields like VARCHAR only use the space required. That makes them far more efficient for most business data.
Then there is Unicode. NVARCHAR and NCHAR support international characters like accents and umlauts. Since modern systems and global users are the norm, NVARCHAR should be your default choice. Storage is cheap, compatibility is priceless, and it keeps you aligned with how Access already stores text.
For sizing, you do not want to fall into the classic beginner trap of making every field 255 characters just because you can. SQL Server actually uses declared lengths when calculating indexes and query plans. Oversizing fields can hurt performance in larger systems. A good rule of thumb is 50 characters for names, maybe 100 if you want extra breathing room, and 255 for emails.
For large notes or comments, use NVARCHAR(MAX). This is similar to the Long Text or Memo field in Access and can store very large amounts of text. Most systems will never hit its limits, but it is there when you need it.
You will also see an Allow Nulls setting. This works like the Required property in Access. Turn it off for fields that must have data, like primary keys or required names. But do not force users to enter junk just to satisfy a rule. No data is better than bad data. You can always query later for missing information.
While defining fields, stick to clean naming conventions. Avoid spaces, dashes, and weird characters. Yes, SQL Server allows them. No, you should not use them. Every space forces you to wrap field names in brackets in queries and code. Stick with simple names like CustomerID, FirstName, and Email. Your future self will thank you.
As you explore the Tables area in SQL Server, you will see other categories like system tables, file tables, external tables, and graph tables. These serve specialized purposes. System tables manage SQL Server itself. File tables allow file storage integration. External tables link outside data. Graph tables model complex relationships. All useful, none necessary for building a basic business application. Focus on standard user tables first.
One related design tip worth mentioning. Do not store files like PDFs or images directly inside your database unless you truly need to. Whether you are using Access or SQL Server, storing file paths is usually simpler, faster, and easier to maintain. SQL Server can store files internally, but it adds complexity most beginner systems do not need.
Once your fields are defined, save the table and give it a proper name, something like CustomerT if you follow my naming conventions. You now have the foundation of your first real SQL Server table, complete with identity field, primary key, and properly sized Unicode text fields.
Getting this structure right at the start makes everything else easier. Relationships, queries, forms, reports, all of it builds on this foundation. Take the extra time now so you are not rebuilding it later.
If you want to see the full step by step walkthrough, including where all the settings live on screen, check out the embedded video above.
Every few months like clockwork, another article pops up declaring that Microsoft Access is dead, obsolete, or being quietly replaced by something newer and shinier. And every time I see one, I feel compelled to dust off the same response. Not because I enjoy arguing on the internet, but because the narrative keeps getting repeated without much real-world context. If you actually build business systems for a living, the story looks very different.
Let’s start with the biggest misconception right out of the gate. Microsoft Access is not just a file sitting on your hard drive. It is a development platform. Treating it like a glorified spreadsheet or a single flat database file is where most of the criticism begins, and where most of it goes off the rails.
You have probably heard the famous “2GB limit” argument. On paper, yes, an individual ACCDB file cannot exceed 2GB. That sounds terrifying if you stop reading there. But that is not how Access is deployed in production. Real-world systems are almost always split databases. The front end contains the forms, reports, queries, and VBA code, while the back end holds only the data tables.
Once you split the database, that 2GB ceiling stops being a practical limitation. You can link multiple back-end files, archive historical data, or move the data entirely into SQL Server, including the free SQL Express edition. I have systems running Access front ends against enterprise SQL Server databases with millions of records. At that point, worrying about a 2GB file cap is like judging a truck’s hauling capacity by the size of its glove compartment.
Another talking point that refuses to die is database corruption. Critics love to frame Access as fragile, ready to implode the moment two users log in. There is a kernel of truth there, but context matters. If multiple users open the same unsplit database file across Wi-Fi, yes, corruption risk goes up. But that deployment model has been considered bad practice for decades.
Proper architecture uses a local front end on each workstation connected to a shared back end on a server, or better yet, a SQL Server data store. Under that model, corruption is rare and usually repairable using built-in compact and repair tools. Blaming Access for corruption in badly deployed environments is like blaming a car for engine failure because someone never changed the oil.
Then we get the “Windows-only” argument. Guilty as charged. Access is a Windows desktop application. But whether that is a limitation depends entirely on your environment. Many organizations are already Windows-based from top to bottom. Employees spend their entire day on Windows machines. In those scenarios, Access being Windows-only is a non-issue.
And when mobile or browser access is required, Access does not have to stand alone. It can connect to shared data that is also exposed through web apps, remote desktops, or Power Apps overlays. Access becomes one interface among many, not the only doorway into the data.
Security is another favorite criticism, especially around row-level permissions. Standing alone, the Access database engine has limited native row-level security. But serious deployments do not rely on Access as the primary security boundary. Security is enforced at the data layer, typically in SQL Server, using Active Directory, server roles, and permission structures.
When Access connects to a secured back end, it inherits that security model. Evaluating Access as if it must single-handedly satisfy enterprise compliance frameworks misunderstands its role in a multi-tier architecture.
You will also hear complaints about Access databases being scattered across file shares, invisible to IT governance. That happens, sure. But it is not an Access problem. Excel files get scattered. PDFs get scattered. Shadow SaaS tools get scattered. Governance is an organizational discipline, not a software feature. Properly managed environments centralize storage, enforce backups, and control deployments regardless of platform.
Some critics point to VBA and macros as a liability, arguing that systems become dependent on the developer who built them. If that person leaves, the system becomes difficult to maintain. That risk exists in every development environment on earth. .NET apps, Python scripts, SQL procedures all have the same dependency risk. The solution is documentation and standards, not abandoning the platform.
Modern discussions often position the Power Platform as Access’s replacement. Microsoft is absolutely investing in Power Apps, Dataverse, and cloud development. But investment does not equal replacement. The two platforms serve different needs. Access excels at rapid desktop development, complex form design, and offline or local-network solutions. Power Apps shines in browser and mobile deployment.
They overlap, but they are complementary tools, not identical substitutes. It is also worth noting that cloud platforms introduce subscription costs that many small and mid-sized organizations simply do not need or want.
Comparisons to SaaS tools like Airtable or Notion come up as well. These platforms are fantastic for collaboration and lightweight relational work. But they do not replace mature Access applications that rely on complex relationships, advanced queries, automation, and reporting. They solve different problems.
None of this means Access is the right solution for every scenario. If you need massive web-scale concurrency, public-facing portals, or mobile-first design, there are better tools. The software landscape has evolved. But evolution expands the toolbox. It does not invalidate tools that still do their job exceptionally well.
Microsoft Access is still supported, still maintained, and still widely deployed. For the right projects, it remains one of the fastest and most cost-effective ways to turn a business need into a working solution.
If you want to see the full walk-through and deeper discussion, be sure to watch the embedded video above.
Ever run a query in Microsoft Access, know for a fact there are hundreds of records behind it, and yet Access politely hands you… 99? No error. No warning. Just a quiet little ceiling on your data. If that has ever happened to you, you are not losing your mind, and your database is not broken. You have just run into one of those tiny hidden settings that can cause a whole lot of confusion if you do not know where to look.
The culprit is something called the Top Values setting. It lives right up in your query design tools, and it controls how many records Access will return. Most of the time it is set to "All," which is exactly what you want. But if it ever gets changed, intentionally or accidentally, your query will quietly stop returning results once it hits that limit. No alarms. No flashing lights. It just stops.
Let’s look at how this happens. Open any query in Design View and look at the ribbon. You will see a dropdown labeled Top Values. If that box says 10, 50, 99, or any other number, that is your cap. Access will return only that many rows, even if your underlying table has thousands.
This setting often gets changed during testing. For example, you might temporarily set Top Values to 100 while building or troubleshooting a query so it runs faster. Then later you forget to set it back. The query works fine, but now your reports or forms that rely on it are mysteriously missing data.
If you switch over to SQL View, you will see this expressed as a clause in the statement itself. It looks like this:
SELECT TOP 99 * FROM Customers;
That TOP keyword is the limiter. Remove it, or change the Top Values dropdown back to All, and suddenly your missing records reappear like magic.
This becomes especially important when queries feed other objects. If you build a form or report on top of a limited query, the limitation carries through. The form is not broken. The report is not filtering incorrectly. It is simply inheriting the row cap from the query underneath.
Another common beginner mistake is assuming the query is filtering data because of criteria, joins, or grouping. People start tearing apart relationships and WHERE clauses trying to fix something that is not even the problem. Always check Top Values first when record counts look suspiciously round.
While we are on the subject of quiet database gotchas, this came up alongside a few related discussions recently. For example, using SharePoint as a backend can introduce its own limitations and performance quirks compared to SQL Server. Another frequent issue involves parameter prompts. If multiple queries all ask for the same date range, the better approach is to pull those values from form controls instead of repeated popups. Different problem, same theme. Small design choices can have big usability consequences.
The big takeaway here is simple. When query results look incomplete, do not panic. Do not assume corruption. Check the basics first. Top Values is one of those tiny switches that can have an outsized impact on what you see.
If you want to watch the full walkthrough, including where to find the setting and how it behaves in real time, the video above shows it step by step. But now you know what to look for, and more importantly, why it happens.
So let's talk about this whole "vibe coding" thing.
If you haven't heard the term yet, it basically means you just tell the AI what you want and let it write the code for you, like having a junior developer who never sleeps and doesn't complain about your specs. You stay in the driver's seat conceptually, but the machine is doing most of the typing. In theory, you focus on the idea while the AI handles the syntax, the loops, the plumbing.
Now, I'm not gonna sit here and pretend I'm above it. I use AI for code all the time. If I need a quick function to sort an array, import a text file, or hammer out some boilerplate VBA that I've written a hundred times before, yeah, I'll let the AI do it. I already know how it works. I just don't feel like spending 20 minutes typing something I've had memorized since the first Bush administration. At this point it's muscle memory, not intellectual exercise.
That's where vibe coding makes perfect sense to me. As an experienced developer, it's a power tool. It's like using a nail gun instead of a hammer. I still know how framing works. I'm just getting the job done faster, and with fewer smashed thumbs.
Where I start to get nervous is when people try to build entire applications this way without understanding what's under the hood. I see folks spinning up full websites, business apps, database systems, all by prompting an AI and copy-pasting whatever it spits out. And hey, it works... until it doesn't. And when it doesn't, it usually breaks at 4:55 PM on a Friday. Then what? When something breaks, slows down, corrupts data, or starts throwing errors that make no sense, you're stuck. If you don't understand the fundamentals, you don't even know where to start.
It's like calculators in math class. I'm all for calculators. I use one every day. But you still have to learn arithmetic first. You still need to understand why 4 + 4 equals 8 before you trust the machine telling you the answer. Otherwise you're just blindly accepting output. Same thing here. AI is fantastic at producing results. It is not automatically fantastic at teaching you how to think like a programmer. And thinking like a programmer is the real skill.(1)
Back when I was learning, I typed code line by line out of books and magazines. Half the time I didn't fully understand what I was typing, but the act of doing it built the mental wiring. You learned patterns. Logic. Cause and effect. Debugging instincts. That friction mattered. Copy, paste, run skips that entire growth process.
The car analogy fits here too. You don't need to know how an engine works to drive. That's fine. Casual users can absolutely vibe code their way to a small app, a hobby project, something non-critical. No problem there. But if you want to build cars, design engines, or fix one when it explodes, you better know what's under the hood, preferably before the explosion. Same goes for software. If it's business critical, if money, customers, or data integrity are involved, you cannot rely on vibes alone.
And this isn't a new sci-fi warning either. Star Trek covered this decades ago.
In the original series episode "The Apple", Captain Kirk and the crew encounter a society completely dependent on a machine called Vaal. It runs their lives. Keeps the weather stable. Provides food. Maintains order. Sounds great... until it starts malfunctioning. The people have no idea how anything works because they've never had to think for themselves. The Enterprise shows up and has to save the day, which I'm pretty sure violates at least three sections of the Prime Directive. Hey, even in the 23rd century somebody still has to be the sysadmin. OK, Scotty, time to three-finger-salute this entire planet...
Then you've got a similar theme in The Next Generation episode "When The Bough Breaks". Picard and the crew discover a highly advanced but dying civilization that automated everything, including reproduction and societal systems. Over time they lost the knowledge to maintain their own technology. When things started failing, they couldn't fix them. They had the tools but not the understanding.
Sound familiar?
That's the long-term risk of vibe coding if it's taken to the extreme. If we outsource all understanding to machines, we create a generation of builders who can't repair what they build.
Now, to be fair, AI is not the villain here. It's a tool. A powerful one. I actually agree with the more balanced take I've been seeing lately. Use AI as an assistant, not a replacement. Let it help you debug, explain, prototype, and accelerate. But still learn the fundamentals. Still build projects yourself. Still struggle a little. (2)
Because that struggle is where the real learning happens.
I've also been watching discussions about how coding tutorials are supposedly "dead" because of AI. I don't buy that either. The format might be changing. Attention spans might be shrinking thanks to short-form social media dopamine machines that make learning anything longer than 30 seconds feel like homework. The job market might be fluctuating. But the need for structured learning hasn't gone anywhere. If anything, it's more important now. Because when AI gives you an answer, you still need to know if it's a good answer. That's the part people forget.
In my world, especially working with databases like Access and SQL Server, fundamentals matter even more. Data integrity. Relationships. Indexing. Concurrency. Error handling. You vibe code that stuff wrong and you don't just get a bug, you get corrupted data or a business that can't operate Monday morning, which is a great way to meet your clients' lawyers. That's not a weekend hobby app anymore. That's real-world impact.
So yeah, I'm not anti vibe coding. I use it. I enjoy it. It's fun watching AI spit out Python or VBA or PowerShell scripts on demand. It feels like living in the future, minus the flying cars we were promised. But I'm also old school enough to believe you should still learn how to code if you want to call yourself a developer. Otherwise you're just steering the ship without knowing how the engines work. And if the engines fail, you're adrift, staring at error messages like they're written in ancient Klingon.
So that's my take. Use the tool. Embrace the speed. Enjoy the convenience. Just don't skip the understanding part if your livelihood depends on the software you're building.
Curious where you land on this. Are you using AI to accelerate code you already understand, or are you letting it build things you couldn't explain if they broke tomorrow?
(1) I remember back in high school and college, a lot of kids were convinced half their classes were pointless. You know the type: "Why do I have to learn this stuff? When am I ever going to use algebra? Or chemistry? Or biology?" On the surface, I understand the frustration. Not everyone grows up to be a scientist or an engineer. But that misses the bigger picture. Those subjects aren't just about the raw information. They're about training your brain. They teach logic, sequencing, cause and effect, and how to follow a structured process. It's algorithmic thinking. You might never use the Pythagorean theorem in your day-to-day life, but learning how to apply a formula, follow a repeatable method, and trust a step-by-step system is the real lesson. That mental wiring carries over directly into programming and problem solving whether people realize it or not. What really gets me is when some of those same folks grow up and start loudly questioning well-established science, like climate change or vaccines, while conveniently forgetting they spent half of science class picking dried glue off their hands or trying to light their book bag on fire with a Bunsen burner. It's hard to respect someone's scientific skepticism when they opted out of the learning part back when they had the chance. "Oh really, Nancy? You've 'done your research?' I remember you skipping science class almost every day to go smoke in the bathroom..."
(2) I don't view AI as some looming villain any more than past technological leaps were villains. Computers didn't "destroy society" because they put typewriter manufacturers out of business. Calculators didn't spell the end of civilization because slide rule and abacus makers had to pivot. Automobiles didn't get framed as evil because they replaced horse-drawn transportation. Every major technology shift displaces certain jobs while creating entirely new industries around it. AI is no different. Yes, it's going to automate some roles. That part is unavoidable. But it's also going to open doors for new specialties, new workflows, and new opportunities that didn't exist before. The real skill, as always, is learning how to adapt, how to use the tool effectively, and how to evolve alongside it, because whether people like it or not, AI isn't going anywhere. Just don't fall into the trap of letting it do your thinking for you, because that's the part of the job that actually matters. Embrace it, learn it, use it but don't outsource your understanding to it. Use it to amplify your skills, not replace the need to have them.
Because the moment the tool becomes the only one who knows how your system works, you've already lost control of it.
Ever click a button in Microsoft Access and get smacked with a runtime error because one form tried to talk to another form that was not open? Yeah. Fun times. This is one of those little annoyances that does not happen often, but when it does, it interrupts your workflow and makes your database feel fragile. Today we are going to fix that and make your code a lot more forgiving.
When one form references another in Access, everything works great as long as the target form is open and ready. But the moment it is closed, or not in the right state, Access throws an error. A common example is refreshing data on another form. If that form is not available, boom, runtime error. So the first step is learning how to safely check whether a form is open before you try to do anything with it.
The classic solution is a small global function that checks the CurrentProject.AllForms collection to see whether a form is loaded. Something like this:
Public Function IsLoaded(FormName As String) As Boolean
IsLoaded = CurrentProject.AllForms(FormName).IsLoaded End Function
You drop that into a standard module so it is available everywhere. Then you wrap your form references in a simple check. For example, before refreshing another form, you might do this:
If IsLoaded("CustomerF") Then
Forms!CustomerF.Refresh End If
That alone prevents a lot of errors. If the form is not open, your code simply skips the refresh. Nice and clean.
But here is where developers, especially during testing, run into a wrinkle. The IsLoaded function only tells you whether the form is open. It does not tell you how it is open. A form sitting in Design View still counts as loaded. Try refreshing it in that state and Access will still throw an error.
This usually does not affect end users because they should never be in Design View. But developers live there. You are opening objects, closing them, tweaking layouts, testing buttons. That is when these little runtime errors start popping up and slowing you down.
The quick and easy fix is simple error suppression. Right before the line that might fail, add:
On Error Resume Next
This tells Access, "If this line blows up, just move along." So your code becomes:
If IsLoaded("CustomerF") Then
On Error Resume Next
Forms!CustomerF.Refresh
On Error GoTo 0 End If
Now if the form is open in Design View, Layout View, or any other unusable state, Access quietly ignores the refresh attempt. No runtime error. No interruption. Life goes on.
This makes development much smoother. You can click buttons, test features, and not worry about whether every related object is perfectly staged.
However, and this is important, error suppression is not something you want to sprinkle everywhere like parmesan cheese. It has a place, but overuse can hide real problems. If something else breaks in that same block of code, you might never know.
I like to compare excessive use of On Error Resume Next to pulling the batteries out of your smoke detector because it chirps once in a while. Sure, it is quiet now, but you also removed the thing that warns you when there is an actual fire.
The best practice is to use it very selectively. Wrap only the specific line that you know might fail, then immediately restore normal error handling with On Error GoTo 0. That way you get the benefit of smoother execution without masking legitimate bugs.
If you want to go further, the more advanced approach is to check not just whether a form is loaded, but what view it is in. Form View, Design View, Datasheet View, Layout View. That takes a bit more code, but it gives you precise control. For most situations though, selective error suppression does the job just fine.
So the takeaway is simple. Always check whether a form is loaded before referencing it, and when development scenarios introduce edge cases, use targeted error handling to keep your database running smoothly.
If you want to see the full walkthrough, including live demos and expanded examples, watch the embedded video above.
If you’ve spent years working inside Microsoft Access, opening SQL Server Management Studio for the first time can feel like walking onto the bridge of a starship. Buttons everywhere. Folders everywhere. Strange terminology. And about a thousand things you’re afraid to click because you don’t know what might explode. So let’s fix that. Today we’re getting oriented inside SSMS so you know what matters, what doesn’t, and where you should actually be working.
When you first connect to your SQL Server instance, the main window you’re looking at is called Object Explorer. Think of this as the SQL Server equivalent of the Access Navigation Pane. This is your map. It shows you the server, the instance you’re connected to, and all the major containers that hold your databases and server-level objects. If you understand this layout, everything else gets much easier.
At the very top is the server itself. That’s the entire SQL Server environment. Under that is the instance. Many Access users aren’t used to this distinction because Access is file-based. You open an ACCDB file and you’re in. SQL Server is service-based. The instance is the running engine that manages databases, security, storage, and performance.
Under the instance you’ll see a whole tree of folders. This is where new users start to panic. Databases, Security, Server Objects, Replication, Management, and more. Here’s the good news: you can safely ignore most of this when you’re starting out.
The folder you’ll live in is Databases. That’s where your actual data lives. Tables, views, stored queries, relationships, all the stuff you’re used to working with in Access. Everything else in Object Explorer is mostly administrative or enterprise-level tooling.
For example, Security controls logins and permissions. Important later, but not something you need on day one. Server Objects handles linked servers and system-wide features. Replication is for syncing data across multiple servers. Sounds cool, but SQL Server Express can only subscribe to replication, not publish it, so most beginners won’t touch it.
You’ll also see things like Management tools and monitoring utilities. These are powerful, but they’re not where you build databases. Think of them like the backstage maintenance rooms. Useful, but not where the show happens.
Once you expand the Databases folder, you’ll notice system databases already there. These run SQL Server itself. Leave them alone. Don’t create tables in them. Don’t experiment. They’re like Access system tables. Important, but not your workspace.
So let’s create our own database. Right click Databases and choose New Database. Give it a name and you’ll see SQL Server automatically prepares two files. One stores the actual data. The other is the transaction log.
This is one of the biggest structural differences from Access. Access stores everything in one file. SQL Server separates data and logging so it can recover cleanly from crashes and maintain transactional integrity. It’s one of the reasons SQL Server is far more robust in multi-user environments.
You’ll also see file size and autogrowth settings. Access users often worry about database bloat and compacting. SQL Server works differently. It automatically grows as needed and reuses internal space. There’s no routine compact and repair cycle like Access. In fact, shrinking databases regularly is usually discouraged.
The default size and growth settings are fine for most projects. SQL Server is very good at managing its own storage. Beginners almost never need to change these.
You’ll also notice the file path where the database lives. By default this is inside SQL Server’s data directory. Leave it there unless you have a specific reason to move it. Do not store SQL Server databases on external USB drives or inside cloud sync folders like OneDrive or Dropbox. Those environments can cause locking issues, sync conflicts, and even corruption.
If you ever need to move database files, do it through SQL Server tools, not Windows Explorer. You can’t just drag the files around like an Access ACCDB.
Once your database is created, expand it and you’ll see another tree of objects. This is where things start looking more familiar. Tables hold your data. Views are saved queries that live on the server. Database Diagrams let you visualize relationships much like the Access Relationships window.
There’s also a folder called Programmability. This is where server-side code lives. Stored procedures, functions, triggers. Think of these like VBA modules that run directly on the server instead of inside your Access front end.
Triggers in particular are powerful. They fire automatically when data changes. Insert a record, update a field, delete something, the trigger runs. Unlike Access form events, they execute regardless of where the change originated. Access form, import job, external app, doesn’t matter. This makes them extremely useful for enforcing rules and auditing activity.
You’ll also see advanced features like Query Store, Service Broker, and storage architecture tools. These are developer and enterprise-level topics. Important down the road, but not required for getting started.
The key takeaway is simple. Don’t let the interface intimidate you. SQL Server exposes far more infrastructure than Access because it’s designed to run enterprise data systems. But for day-to-day database building, you’ll spend most of your time inside the Tables, Views, and basic database objects.
Once you understand the layout, SSMS stops feeling like a dungeon crawl and starts feeling like a well-organized control panel.
In the next step, you’re ready to start creating tables and actually building something. And that’s where the real fun begins.
If you want to see the full walkthrough, including live navigation and demos, check out the embedded video above.
If you're a Microsoft Access user and you've ever thought, "Maybe it's time to move this database to SQL Server," then congratulations: you're officially at the point where Access starts giving you that side-eye. The good news is SQL Server Express is free, solid, and perfect for learning. The slightly annoying news is that installing SQL Server can feel like assembling IKEA furniture without the pictures. So in this lesson, I'm going to walk you through installing SQL Server Express and SQL Server Management Studio (SSMS) the right way, with zero mystery and minimal suffering.
Before we can link Microsoft Access to SQL Server, we need an actual SQL Server engine running somewhere. In our case, we're keeping it simple: SQL Server running on your local computer (or a computer in your office), and Access connecting to it. That means step one is installing SQL Server Express, and step two is installing SSMS, which is the tool we'll use to actually manage databases, create tables, and generally poke at things until they behave.
Let's start with the important concept that makes everything else make sense: SQL Server Express is the database engine. It's the part that stores the data and responds when Access asks for it. It's basically the "server" part of SQL Server.
SSMS (SQL Server Management Studio) is not SQL Server itself. It's the control panel. It's the tool you use to create databases, design tables, run queries, manage security, and troubleshoot problems when something goes sideways. Think of SQL Server as the engine under the hood, and SSMS as the dashboard.
So the plan is simple: install the engine first (SQL Server Express), then install the dashboard (SSMS).
First, go download SQL Server Express from Microsoft. The exact page and link names may change over time, but the key phrase you're looking for is SQL Server Express and the current version. At the time of writing this, it's SQL Server 2025. If you're reading this in the future and Microsoft has moved on to something newer, just grab the latest Express version. The steps are basically the same.
Once the installer is downloaded, run it. You'll see a couple of choices, and this is where most people blindly click whatever sounds easiest and then wonder why things are confusing later. Choose Custom.
Not because we're doing anything fancy. We're not.
We choose Custom because it lets you actually see what's being installed and where, and it forces you to learn the terminology you'll need later when you're connecting Access to SQL Server and trying to make sense of error messages. The "Basic" install works, sure, but it hides a lot. And since this is a course, we want understanding, not button-mashing.
The installer will ask where to download the setup files. This is not where your databases will live. It's just where the installer temporarily stores the files while it does its thing. The default location is fine. Unless you're dealing with a tiny system drive and you know what you're doing, leave it alone and continue.
Once the download finishes, you'll land in something called the SQL Server Installation Center. It sounds like a place you need a badge to enter, but it's basically just a launcher. Choose the option for a New SQL Server standalone installation.
Then you'll see the license agreement screen, where Microsoft politely asks for your firstborn child and your immortal soul. (I'm kidding. Mostly.) Click accept and move on.
Next you'll hit the update setting. SQL Server can optionally receive updates via Microsoft Update. This is personal preference. I typically turn automatic updates off because I like controlling when things update, since updates can occasionally break things and I prefer discovering that on a weekend and not during a workday. If you're comfortable with auto-updates, it's fine. Either choice is valid. Just pick intentionally and continue.
After that, SQL Server will run an installation rules check. You're looking for one thing: no red X errors. Warnings are usually informational and not fatal. A common warning involves Windows Firewall, and that's normal. We're installing SQL Server locally, not exposing it to the internet. We can adjust firewall rules later if we ever need other computers on the network to connect.
And let me pause for a very important public service announcement: do not expose SQL Server directly to the internet. Yes, it can be done. No, you shouldn't do it unless you're a security professional or you're paying one. I speak from experience. One of the fastest ways to ruin your week is letting random strangers on the internet take a crack at your database server. Use proper hosting or services if you need remote access. For this course, we're keeping things in-house for a reason.
Next, you'll see a screen about Azure extension. Azure is Microsoft's cloud platform, and it's great, but it is not what we're doing here. We're building a local SQL Server setup for Access users. Turn Azure stuff off and continue. You can always explore cloud options later, after you've learned the fundamentals.
Now we get to the features selection screen. For Access users, there is exactly one thing you must install: Database Engine Services.
That's it. That is SQL Server.
The other options are for more advanced scenarios (replication, full text search, PolyBase, etc.). They're not necessary for this course. If something extra is already selected by default, it won't usually hurt anything, but the key takeaway is: Database Engine Services must be selected. Then continue.
Now comes a major vocabulary word: Instance.
This is where Access users tend to get confused because SQL Server terminology doesn't match Access terminology. In Access, you have one database file (ACCDB) and that's basically the whole universe. SQL Server doesn't work like that.
An instance is a running copy of SQL Server installed on a machine. One SQL Server instance can contain multiple databases inside it.
So think of it like this: the instance is the container, and your databases live inside that container.
SQL Server Express installs by default as a named instance called SQLEXPRESS. Keep it that way. Seriously. Leave it alone. Using the default makes everything easier, especially when you're learning. Later, you can install other instances if you truly need them, but most people never do.
Next you'll see server configuration settings (services, startup types, accounts, etc.). For almost all local learning and small office setups, the default settings are fine. This is where enterprise administrators spend their lives tuning things. We are not doing that in this course. Leave the defaults and continue.
Then you'll hit the authentication mode screen. Choose Windows Authentication.
This is the best option for in-house setups because it uses your Windows login. No separate SQL password. No storing credentials. And it integrates very naturally with Access.
And no, you do not need a Windows domain. Windows authentication works in peer-to-peer networks too, as long as the users who need access have Windows logins that exist on the SQL Server machine.
For example, imagine a tiny office with three people: Joe, Bob, and Sue. Everyone has their own computer, and Bob's machine becomes the SQL Server machine (because Bob is the "database guy"). If Joe and Sue need to use Access linked tables against SQL Server on Bob's computer, they just need accounts on Bob's machine. Many offices keep it simple by using the same username/password across all PCs for each user. Totally normal.
Once you click next, SQL Server installs the engine. This part might take several minutes. It's a great time to grab coffee, pet the dog, or tell yourself you're going to reorganize your office later (you won't, but it's nice to dream).
When it's finished, you should see green check marks and "Install successful." If not, don't panic. Post in the forums and we'll troubleshoot it, but in most cases the install is smooth.
At this point, the SQL Server engine is installed and running. Now we just need SSMS so we can manage it.
Go download SQL Server Management Studio (SSMS) from Microsoft. Note that Microsoft now ships SSMS separately. Years ago it was bundled, but not anymore. This is actually a good thing because it means you can install SSMS on your workstation and manage SQL Server on a different machine, which is common in real-world setups.
Run the SSMS installer. For our purposes, the defaults are fine. Install it and let it finish.
You may be prompted to restart Windows afterward, especially on a fresh SQL Server setup. If you're prompted, restart. Don't skip it. SQL Server installs a bunch of services and components, and you'll save yourself a lot of weirdness by doing a clean reboot now.
Once SSMS is installed, launch it. I recommend pinning it to your taskbar because you'll be using it constantly throughout this course.
SSMS may ask you to sign into a Microsoft or GitHub account. You can skip that. It's not required to use SSMS or connect to SQL Server. That's mainly for syncing settings and cloud-related features. We're staying local and simple.
Now you'll see the connection screen. This is where everything clicks together.
The Server name format is:
ComputerName\InstanceName
So if your computer is named KIRK (because you're a Star Trek nerd like me), and you installed the default instance SQLEXPRESS, your server name would be:
KIRK\SQLEXPRESS
Choose Windows Authentication and click Connect.
You may see an error that looks scary, something like a connection warning involving encryption and certificates. On a new local install, this is often the famous "self-signed certificate" message. Translation: SQL Server is trying to encrypt the connection, but Windows doesn't automatically trust the certificate because SQL Server created it itself. On a local training system or in-house setup, this is normal.
The fix is simple: check the box that says Trust server certificate and connect again.
In a big corporate or internet-facing environment, you'd install a proper certificate from a trusted authority. But for local and in-house use, trusting the server certificate is perfectly normal and very common.
Once connected, you'll see the Object Explorer on the left and you're officially in business. SQL Server is installed, SSMS is working, and you're ready for the fun part: actually building databases and connecting Access to them.
And yes, in the next lessons we'll start creating tables, learning the SQL Server equivalents of Access concepts, and eventually linking your Access front-end to SQL Server tables like it was born to do it.
If you want the full screen-by-screen walkthrough, the embedded video above will walk you through the entire process exactly as shown. But if you followed this article, you should now understand what you're installing, why you're choosing those options, and what to do when SQL Server throws one of its dramatic little warnings at you.
Let me guess... you keep hearing the words “SQL Server” and your brain immediately jumps to corporate IT departments, thousand-dollar licenses, cloud dashboards, and a guy named Todd who makes you submit a ticket to change your password. Yeah... no. Not what we’re doing here. In this lesson, I’m going to show you what SQL Server actually is (and what it definitely is not), why Microsoft Access users move up to it, and why you don’t need to “abandon Access” to do it.
The most important thing to understand right from the start is this: SQL Server is not a replacement for Microsoft Access. It’s an upgrade to what’s underneath it. You still build your forms, reports, queries, VBA code, and all the user interface stuff in Access. SQL Server simply becomes the place where your data lives... more securely, more efficiently, and with a whole lot less risk of someone doing something dumb and expensive.
So what is SQL Server?
SQL Server is a database engine. It runs quietly in the background as a Windows service. You don’t double-click it like an Access database file. You don’t “open” SQL Server the way you open an ACCDB. SQL Server just sits there like a well-trained guard dog, waiting for authorized applications to connect and ask for data.
And in our case, that application is Microsoft Access.
Think of Access as your front end: the stuff people see. The forms, buttons, reports, dashboards, search screens, and the things users click on when they’re pretending they “don’t do computers.” SQL Server is the back end: the vault where the data is stored, protected, and served up only when requested.
That alone is a major shift from how shared Access backends work.
With Access, the database is the file. If your backend is sitting in a shared folder, then every user must have read/write access to the file. And if they have access to the file, they can copy it. If they can copy it, they can open it. And if they can open it... they can see everything inside it. Tables, customer data, confidential notes, credit cards (please don’t), and yes, they can delete your stuff too.
I’ve literally had clients call me because a disgruntled employee deleted the backend database file and walked out with a copy of it on a thumb drive. Not because Access is “bad.” Because Access is file-based, and file-based systems have limitations. That’s just reality.
Now SQL Server changes that completely.
With SQL Server, users never touch the database file. In fact, most users couldn’t even find it if you offered them $100 and a map. Their Access front end sends requests to the SQL Server, and SQL Server decides what they’re allowed to see and do.
That’s where the big win happens: permissions.
You can allow a user to read certain tables but not others. You can allow updates but prevent deletes. You can hide entire sections of data. SQL Server enforces security at the server level, not the “hope nobody clicks the wrong thing” level. And if someone’s angry and wants to cause damage, they can’t just grab the database and walk away with it like they’re stealing snacks from a vending machine.
This matters even more when you’re dealing with sensitive data. Credit card numbers are the classic example. Medical information, personal identity data, financial records... these are things that should never be sitting in a shared Access backend file on a network drive. SQL Server supports encryption, auditing, controlled access, and real security. In some industries, it’s not even optional. It’s policy. It’s regulation. It’s the law. This isn’t paranoia. It’s responsible database design.
Now let’s talk about one of my favorite analogies for this.
A shared Microsoft Access backend is like a restaurant with a big open salad bar.
The food is just out there. Anybody can walk up. No one is checking plates. No one is monitoring what you’re allowed to take. And once you’re in the buffet area, you can touch everything. We’ve all seen it: little kids sticking their grubby fingers in the croutons, people reaching over each other, and someone sneezes within six inches of the lettuce. It’s chaos. It’s uncontrolled access.
That’s basically a shared Access backend. If a user can open the file, they’re standing at the buffet. They can see everything, copy everything, delete everything, or take the whole tray and leave the building.
SQL Server, on the other hand, is fine dining.
You don’t walk into the kitchen. You don’t open the fridge. You sit at a table and you place an order with a waiter. The waiter checks the menu, confirms it’s available (not “86ed”), and sends the request to the kitchen. The kitchen prepares exactly what you’re allowed to have, and the waiter delivers it back to your table.
That’s SQL Server.
Users submit requests through Access. SQL Server checks permissions. SQL Server returns only what they’re allowed to have. The server stays in control the entire time. Where would you rather eat?
Now let’s squash another big misconception.
A lot of people hear “SQL Server” and assume you need a big corporate network, a domain controller, and an IT department. Nope. Not for what we’re doing here.
We’re using SQL Server Express, which is free. It installs right on Windows 11. You don’t need Windows Server. You can even install it on the same machine you’re using to build your Access databases. And it works great in small offices running a basic peer-to-peer network.
You can absolutely run SQL Server locally in-house and still get the biggest benefits: security, performance, and scalability. No cloud required.
Now yes, there are hosted versions of SQL Server. Microsoft calls theirs Azure, which is basically SQL Server living on Microsoft’s servers. There are also third-party hosting companies like Winhost (the provider I recommend and personally use) that offer hosted SQL Server as well. Those are great when you need outside access or don’t want to manage any hardware yourself.
But the key point is: the cloud is optional. SQL Server itself is the upgrade, and you can deploy it however you want.
Next big benefit: performance.
Let’s say you have a million orders in your Orders table and you want to find ten of them. With a shared Access backend, Access often pulls large chunks of data across the network to your PC, then processes it locally. That means a lot of network traffic, a lot of waiting, and a lot of unnecessary “work” happening on every user machine.
SQL Server flips that around.
With SQL Server, the server processes the query right where the data lives, then sends back only the rows you need. Not the whole table. Not 200,000 records to sift through. Just the ten results. Less network traffic. Faster performance. Happier users. Less coffee consumed while staring at a frozen form.
This is one of the main reasons Access databases feel fast when the data is local, but slow when the backend is shared over the network. It’s not always the number of users. It’s the architecture. With SQL Server, you stop dragging data across the network just to do work on it.
Or as I like to say: don’t drag the data to the work... bring the work to the data.
And this leads into scalability.
People often think SQL Server only becomes worthwhile when you have dozens of users. I disagree. Even with three, four, or five employees, security starts to matter. Risk starts to matter. And performance becomes noticeable quickly as your data grows.
But once you start scaling up, the difference becomes huge.
With a shared Access backend, the more users you add, the more network traffic you create, and the more processing happens on each PC. Things slow down. Corruption becomes more likely. Somebody starts complaining, “It was working fine last year!” (Yes, because last year you had 8,000 records. Now you have 800,000.)
With SQL Server, the architecture doesn’t change when you grow. Five users, fifty users, five hundred users. It’s still Access front ends sending requests to SQL Server. SQL Server is designed for this. It is literally its job. I’ve personally built systems with 150-200 users all running Access front ends connected to SQL Server, and they ran just fine.
And if you ever need to go bigger, SQL Server can scale to thousands or tens of thousands of users. The important part is: you don’t have to start at that level. SQL Server lets your database grow at the same pace as your business, without hitting a hard wall where everything breaks.
So what are we going to build in this course?
We’re keeping it simple and practical.
First, we’ll install SQL Server Express and SQL Server Management Studio (SSMS). SSMS is the tool you use to manage SQL Server, create tables, create views, manage security, and run queries. Both SQL Server Express and SSMS are free downloads from Microsoft.
Then we’ll create a simple table so you can see how SQL Server compares to Access tables. We’ll build a query and save it as a view (that’s basically SQL Server’s version of a saved query). We’ll talk about differences between Access SQL and SQL Server SQL (which is called T-SQL, because yes, tech people love abbreviations).
And finally, we’ll connect an Access database to SQL Server so you can see the whole pipeline working end-to-end: Access forms and queries using data stored in SQL Server.
This course is primarily designed for Access users, so I’m assuming you already understand the basics: tables, queries, relationships, primary keys, and how Access applications are put together.
If you’re brand new to Access, I strongly recommend starting with my Access Beginner courses first. I’ve got a completely free Access Beginner Level 1 course that’s about four hours long and covers the fundamentals. SQL Server will make a lot more sense once you’ve got that foundation.
Also, I strongly recommend you understand proper table design, normalization, and relationships. SQL Server is much less forgiving than Access when your design is sloppy. If you’re still storing multiple values in one field or building “one table to rule them all,” SQL Server is going to smack you upside the head. (Not literally... it’s passive-aggressive like that.)
A working knowledge of SQL is also recommended. You don’t need to be an SQL wizard, but you should be comfortable writing basic SELECT queries, using WHERE clauses, ORDER BY, joins, and understanding how queries drive forms and reports.
If your SQL skills feel rusty, I also have a three-part SQL seminar series that focuses on SQL in Microsoft Access. It’s optional, but it can help a lot before you step into the SQL Server world.
And no, you don’t need to be a VBA developer to benefit from SQL Server. You can absolutely use SQL Server as a backend with linked tables and Access queries without writing code. But if you do like VBA, the developer series of this course will cover advanced techniques like connecting without linked tables, executing SQL Server logic from VBA, stored procedures, and building more secure and flexible systems.
Now for the big takeaway, because I want you to really tattoo this on your brain:
You do not stop being an Access developer when you start using SQL Server.
You become a better Access developer.
Same tools. Same front end. Same skills. But now your application has a stronger foundation underneath it: better security, better performance, and the ability to grow without collapsing under its own weight.
If you understand Access, you already understand most of what you need. SQL Server builds on the same concepts, just in a more controlled and professional environment.
So don’t think of this as “leaving Access behind.” Think of it as leveling up what you already know.
And with that big-picture overview out of the way, in the next lesson we’ll stop talking about SQL Server and actually install it: SQL Server Express and SQL Server Management Studio. You’re going to see it’s not scary at all.
If you want the full walk-through, examples, and on-screen setup, watch the embedded video above. But you should now understand what SQL Server is, why Access users use it, and why it’s such a powerful next step.
