Customer Table, Part 1

Building a Customer Table In SQL Server, Text Data Types And Identity Primary Key

from Computer Learning Zone News https://599cd.com/SQLSAB01L04

Microsoft Access Is Not Dying: Debunking the Myths, Limits, and Replacement Hype

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.

Live long and prosper,
RR

dotnet run

dotnet run by Alex Hedley

from Computer Learning Zone News https://599cd.com/3786

The Setting That Silently Limits Microsoft Access Query Results That You Might Not Know Exists QQ#78

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.

Live long and prosper,
RR

Vibe Coding and the Illusion of Understanding

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?

LLAP
RR

(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.

Live long and prosper,
RR

Stop Microsoft Access Form Errors When Referencing Other Forms That Are Not Ready Yet

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.

Live long and prosper,
RR

SQL Server Management Studio Interface Overview for Microsoft Access Users Getting Started

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.

Live long and prosper,
RR