Why Access Won
By Richard Rost
3 days ago
Truth About Access and Why It Dominated Databases In this lesson, we discuss why Access won market share during the transition from DOS to Windows, including its pricing, Office distribution, and integrated tools for tables, queries, forms, reports, and automation. We also compare Access with dBASE, FoxPro, Paradox, and Clipper, clarify the timeline of Rushmore technology, and discuss when Access works well today, including using it as a front end with SQL Server. PrerequisitesLinksRecommended Courses
Keywords TechHelp Access, Microsoft Access vs FoxPro, Access worst database, Access history, FoxPro Rushmore optimization, Access 1.0, Access 2.0, Visual FoxPro discontinued, dBASE, Paradox database, Clipper compiler, Access SQL Server frontend, Office Professional
Subscribe to Why Access Won
Get notifications when this page is updated
More InformationTranscript Calling Microsoft Access the worst database is certainly one way to get my attention. But does the history actually support that label?
Welcome to another TechHelp video brought to you by Access Learning Zone. I'm your instructor, Richard Rost.
Today, I'm responding to a video about how Access became so successful even though that video's thumbnail calls it the worst database. I want to look at what that video gets right, where I disagree, and what it leaves out about actually building something useful with Access.
One of my students, David, shared this video in my website forum. It's from Tech History Channel, and you can see the thumbnail here. I'll put a link to it down below if you want to watch the original.
The video looks back at Access and competitors like dBASE, FoxPro, and Paradox. It puts a lot of emphasis on Microsoft's timing, pricing, and distribution while describing technical advantages some of those other products had.
Now, I've worked with Access since 1994. I'm a Microsoft MVP, and I was working with other database products back in the 80s and early 90s. So I know a thing or two about this stuff.
Now, after watching his video a second time, I don't think he's trash-talking Access nearly as much as the thumbnail suggests, but he definitely picked a thumbnail to get views by calling Access the worst database. And so that's one of the things I disagree with, and there's quite a bit in his video I agree with as well. So let's take a look.
Now, in a nutshell, he's right that arriving on Windows, offering an aggressive introductory price, and later getting into Office gave Access an enormous advantage. My disagreement is with the leap from competitors having technical strengths, especially speed, to that worst database label.
In particular, he emphasizes FoxPro's speed as an advantage over Access, and that is worth discussing. But a business also needs a way to enter an order, print an invoice, and get a useful report. Access brought tables, queries, forms, reports, and automation together so people could build that whole application. So you have to include that in the comparison.
Now, timing and distribution helped Access get chosen, and it's useful, and this gave people reasons to keep building with it.
So let's start with the history he gets right because that explains the situation Access arrived in. One of his main points is that Access benefited from the move from DOS to Windows.
If you weren't using computers then, DOS was the world of text-based screens, typed commands, and keyboard-driven menus, for those of us who are old, though. Businesses were already running databases built with products like dBASE, FoxPro, and Paradox. Lots of developers, myself included, spent years building applications with tools like those.
Then Windows changed what people expected software to look and feel like. They wanted Windows, buttons, and a mouse-driven interface without losing the business systems they already depended on.
So that put those established products in a tricky position. They needed to attract Windows users while looking after customers with existing DOS applications. Some old applications could run unchanged, so this wasn't always a complete rewrite. But turning an old screen into a good Windows interface, adapting reports, and preserving the way existing code behaved took real work.
The competitors did produce Windows versions, but Access's advantage was arriving as a Windows product without its own older DOS application base to carry along with it. And that's a fair point in his video.
He also points to price and Office. And I agree with him there, too. Access launched with a $99 introductory price, and the other databases at the time were much more expensive. That made trying Access easier, although it wasn't the permanent price.
Later, Microsoft included it in Office Professional. Not every Office edition and not at the original standalone launch. But imagine your office already buying Microsoft's other applications and getting a database tool in that package. Of course that helps.
That's how I personally started using Access. It was included in my Microsoft Office copy that I got with Word and Excel and PowerPoint. I'm like, oh, what's this Access thing? Let's give it a try.
Now, to me, that was a sensible business strategy. The question is what people found once they started using it.
Now, here's where I take a little umbrage with that worst database thumbnail. The video gives you reasons a competitor might be faster or more mature than early Access was. But before we call one product better, we need to ask: better at what?
Now, I wouldn't call Access 1.0 a great piece of software. In my view, even 2.0 had plenty of room for improvement. That's the version I started working with.
Now, those early versions still did useful work. And it was a brand-new product competing with tools that had years of maturity behind them. So we ought to be clear about which version and which job we're comparing.
The thumbnail also bothers me because it can leave someone with the impression that Access is still the worst database today. That's how it reads to me. Even though the video itself is more balanced, if the evidence is that another product handled certain operations faster, that tells us about those operations. We still haven't evaluated the rest of the application.
Suppose one tool runs your query faster, but another lets you build the order entry screen better, the invoice, and the monthly report with less work. Which one is better for your business?
Your employee comes in on Monday morning needing to enter an order and get it shipped. The query is part of the job, but it isn't the whole job. And yes, speed matters. No one wants to sit there waiting for every button click, but I'm asking us to include development time, ease of use, reporting, and the work involved when someone needs a change.
And here's what that looks like in an ordinary little business database. Let's say we're building an order system for Orion Traders. We put the customers in one table, the orders in another. Our relationship connects each order to its customer, so we aren't typing the customer's details over and over again for every sale.
A query can pull together the orders we need and calculate their totals. That's the data side.
Now somebody has to use it. We build a form where an employee can select the customer and enter an order. We build a report that turns that information into an invoice, and we can automate routine actions like opening the right report from a button instead of making the employee repeat a bunch of steps.
Now Access gives you the tools to build all those pieces in one environment. You can get started with its designers and add programming as the application needs more. That's the practical value I want included when we're comparing it with other products. How much work does it take to get from a business problem to something people can actually use?
Now, you don't have to follow those little boxes in this exact order when you build a database. The diagram just shows how the pieces are connected, and that connection matters after the application is built, too.
Now let's stay with Orion Traders for a minute. Next month, the owner wants a report showing which customers haven't ordered lately. Somebody has to figure out the query, make the report readable, and give the staff an easy way to open it.
That ongoing work belongs in the comparison just as much as how quickly the query runs. The original video's emphasis on pricing and distribution can leave that part of the story in the background.
But there were developers who chose early Access because they liked what it could do. Luke Chung at FMS wrote about that firsthand. His company had developed tools for Paradox, and he described being impressed by Access's table design, relationships, queries, forms, reports, and how it all fit together.
That's one developer's account, not a test proving Access beat every competitor, but FMS went on to build a business around Access, so keep that perspective in mind. It gives us a concrete example of somebody who knew the alternatives and saw useful capabilities in Access. And the low price wasn't the only thing we're talking about.
Now, of course, those alternatives deserve some credit, too. The source video talks about dBASE, FoxPro, Paradox, and Clipper as the established competition. And these weren't toys. People built serious applications with them.
FoxPro had real data processing strengths, dBASE had an important language and developer community, and Paradox was a capable database development tool in itself.
Clipper also needs a little explanation. It was a compiler and development tool associated with the dBASE language. A compiler turns your program into something you can run, so listing all these products together doesn't mean they were interchangeable database engines. Their development tools and the way you built and delivered applications mattered, too.
I worked with other database products in that period before I started with Access in 1994, and I'm certainly not saying nothing useful existed before Access came along. My point is that you can respect what those tools did well and still see why somebody preferred Access for a particular job.
And when we're comparing their technology, we need to get the versions and the dates right. And that brings us to Rushmore.
In the original video, the discussion of Microsoft's Fox acquisition and Rushmore runs into the story of Access's 1992 launch, giving the impression that the technology was already in Access at launch. Rushmore was FoxPro's query optimization technology. In plain English, it helped speed up finding the records in a query.
Microsoft's own history dates the Access availability announcement to December 16, 1992. The contemporary Byte coverage of Access 2.0 in April 1994 describes Microsoft adding FoxPro's Rushmore technology to improve set query performance over Access 1.1. So that's an Access 2.0 improvement.
We shouldn't move it backward into the launch of Access 1.0. If we're explaining how the first version competed, giving it a feature from a later version changes the story.
Now, FoxPro deserves credit for that technology, and Access deserves to be evaluated as it developed rather than having every version treated as the same product. And that's why I'm being a little fussy about the timeline.
It also helps with another claim in the video: why Microsoft eventually stopped developing FoxPro. At the end, he presents FoxPro's discontinuation as a calculated move to make Access dominant. And that's an explanation of Microsoft's motive. And it needs more support than simply showing that Microsoft bought Fox and then later stopped developing the product.
The acquisition was in 1992. FoxPro continued for years afterward, with Visual FoxPro 9.0 arriving in 2004 and extended support ending in January of 2015. So if you hear that Microsoft bought FoxPro and just killed it, don't picture it disappearing right after the purchase. There's a long product history in between there.
Now, we can also point to useful technology making its way into Access, as with Rushmore. My interpretation is that Microsoft used technology from FoxPro in other products and eventually decided to consolidate. Companies do that. And I don't automatically see it as sinister.
But my explanation of why they ultimately discontinued it is an interpretation, too. We haven't established that as Microsoft's documented reason.
Now, none of that makes the disappointment any less real for developers who relied on FoxPro. It just means we should separate the events we can check from the reasons we're assigning to them.
The same caution applies when we talk about what Access can do today.
Now, defending Access doesn't mean I'm recommending it for every database problem. If you're choosing a system now, look at how much data you've got, how many people will be working at once, the security that you need, and where the application has to run. Those requirements matter more than winning an argument about a product name.
Sometimes a server database like SQL Server is the right place for the data. But remember our order entry example from before. You can keep those in Access. This can connect to SQL Server tables, giving users the forms and reports they're familiar with while SQL Server handles the data behind them.
I talk about this in a lot of my videos. Now, that still takes planning and testing, and moving tables to a server doesn't automatically fix every slow query or every security problem. You still have to design the application for that setup, but it's a useful option that gets lost when the discussion is reduced to Access versus some other database.
I hear this all the time. Well, Access doesn't do this. Access doesn't have that security. Access can. Of course, Access is a front end. Mix it with SQL Server, and you've got a fantastic solution.
And you can choose different pieces for different parts of the job. The question is what works for your users, your business, and your application.
So, coming back to the video that David shared, I agree with the broad historical argument that Windows, pricing, and Office distribution definitely helped Access succeed. The established competitors faced real challenges as the market changed.
Where I disagree is the worst database label and the impression it can leave about Access today. For the kinds of business applications that I build and teach, Access is still my first choice. This combination of development tools and database features matters to that choice. And I think that usefulness deserves a bigger place in the story of why it lasted.
Popularity by itself doesn't prove technical superiority. A faster query in another product doesn't settle the whole comparison either. Show me what you're building, what your users need, and how much work each tool makes you do. Then we can have a useful discussion about which one fits.
I hope this gives everyone some context, whether you watch the original video or if this is the first you've heard about it. And if you'd like to keep going with this discussion, take a look at my video on whether Microsoft Access is still worth learning. That looks at the question from the point of view of somebody deciding where to spend their learning time.
And if you're new to Access and want to see how all those tables, queries, forms, and reports actually come together, start with my free Access Beginner Level 1 course. We'll get you working with the basic pieces so you can start building something yourself and see how easy it is.
So now you know why the Windows transition, pricing, and Office helped Access succeed, and why a fair comparison also has to include the work of building and using a complete business application.
And, of course, I look forward to your comments down below. Go ahead and post them and let me know what you thought about today's video and what you thought about the original video and if you've watched it or not.
But that's going to be your TechHelp video for today. I hope you learned something. Live long and prosper, my friends. I'll see you next time. Intro In this lesson, we discuss why Access won market share during the transition from DOS to Windows, including its pricing, Office distribution, and integrated tools for tables, queries, forms, reports, and automation. We also compare Access with dBASE, FoxPro, Paradox, and Clipper, clarify the timeline of Rushmore technology, and discuss when Access works well today, including using it as a front end with SQL Server. Quiz Q1. What factors helped Microsoft Access gain a strong position in the database market?
A. Its Windows focus, introductory pricing, and later inclusion with Office
B. Its exclusive support for DOS applications
C. Its ability to replace all server databases
D. Its requirement for advanced programming before creating forms
Q2. Why was the move from DOS to Windows challenging for older database products?
A. Windows could not display database records
B. Developers had to adapt existing applications to a graphical, mouse-driven interface
C. DOS databases stopped storing data correctly
D. Businesses no longer needed reports and forms
Q3. Why is calling Access the "worst database" an incomplete comparison?
A. Access cannot create queries
B. Database products should be compared only by their price
C. Query speed alone does not measure application development, reporting, usability, and maintenance
D. Access was never intended for business applications
Q4. Which set of features makes Access useful for building complete business applications?
A. Tables, queries, forms, reports, and automation
B. Only spreadsheets and charts
C. Only server-side stored procedures
D. Only command-line scripting tools
Q5. In the Orion Traders example, why are customers stored separately from orders?
A. To prevent employees from viewing customer names
B. To avoid entering the same customer details repeatedly for every order
C. To make reports impossible to print
D. To eliminate the need for queries
Q6. What is the main purpose of a form in an Access business application?
A. To provide an interface for users to enter and view data
B. To permanently store all database records
C. To replace all queries
D. To encrypt a server database
Q7. What is the main purpose of a report in an Access application?
A. To provide a readable formatted output such as an invoice
B. To define table relationships
C. To replace the data entry form
D. To speed up all database queries automatically
Q8. Why should ongoing changes be included when comparing database development tools?
A. Business requirements never change after deployment
B. A tool should make it practical to update queries, reports, and user interfaces as needs change
C. Only the original development time matters
D. Reports should never be changed after they are created
Q9. What was an important strength associated with FoxPro in the discussion?
A. It had strong data-processing and query-performance capabilities
B. It was included in every Office package
C. It did not use tables
D. It could only run on the web
Q10. Why is it important to distinguish Clipper from products such as Access and FoxPro?
A. Clipper was primarily a compiler and development tool associated with the dBASE language
B. Clipper was a spreadsheet program
C. Clipper was an Office application
D. Clipper was a hardware database server
Q11. What was Rushmore designed to improve?
A. The speed of finding records for query operations
B. The visual appearance of Access forms
C. The printing quality of reports
D. The security of user passwords
Q12. Why does the video emphasize getting product timelines right?
A. Features from later releases should not be credited to the original product launch
B. All database products were released at the same time
C. Dates are more important than application design
D. Older software cannot be compared with newer software
Q13. What is the careful conclusion about Microsoft's decision to discontinue FoxPro?
A. It is proven that Microsoft ended it immediately after acquiring it
B. FoxPro disappeared before Microsoft acquired it
C. The exact motive should not be stated as fact without documented evidence
D. FoxPro was discontinued because it could not process data
Q14. When might SQL Server be a better place to store application data?
A. When the application has greater data volume, concurrent users, or security requirements
B. When users need to print an invoice
C. When a database needs a customer table
D. When a developer wants to create a form
Q15. How can Access and SQL Server work together in a business application?
A. Access can provide forms and reports while SQL Server stores and manages the data
B. Access must replace SQL Server entirely
C. SQL Server can only be used for printing reports
D. Access cannot connect to SQL Server tables
Q16. Why does moving tables to a server not automatically solve every problem?
A. Application design, query design, security, and testing still matter
B. Server databases cannot store tables
C. Forms stop working when data is stored on a server
D. Reports cannot use server data
Q17. What is the best way to choose between Access and another database tool?
A. Choose the product with the most dramatic thumbnail
B. Choose based on the business problem, user needs, data size, security, and deployment requirements
C. Always choose the fastest query engine regardless of other needs
D. Always choose the newest product
Q18. What is the main argument for Access remaining useful today?
A. It can help developers build complete business applications efficiently, especially when combined with appropriate back-end systems
B. It is the only database tool that can create tables
C. It is always the best choice for every possible application
D. It eliminates the need for planning and testing
Answers: 1-A; 2-B; 3-C; 4-A; 5-B; 6-A; 7-A; 8-B; 9-A; 10-A; 11-A; 12-A; 13-C; 14-A; 15-A; 16-A; 17-B; 18-A
DISCLAIMER: Quiz questions are AI generated. If you find any that are wrong, don't make sense, or aren't related to the video topic at hand, then please post a comment and let me know. Thanks. Summary Today's video from Access Learning Zone addresses the claim that Microsoft Access was the "worst database" and asks whether the history actually supports that label.
I recently watched a video from the Tech History Channel discussing how Microsoft Access became successful despite being described in its thumbnail as the worst database. The video compares Access with products such as dBASE, FoxPro, Paradox, and Clipper. It focuses heavily on Microsoft's timing, pricing, Office distribution, and the technical strengths of competing products.
I have been working with Access since 1994, and I was working with other database products during the 1980s and early 1990s. I have seen the transition from DOS-based database development to Windows-based development firsthand. After watching the original video more than once, I do not think the creator was as harsh on Access as the thumbnail suggests. Much of the history presented is reasonable. However, I disagree with the "worst database" label and with the conclusions that some viewers may draw from it.
The historical background is important. During the DOS era, business software was largely text-based. Users navigated menus with the keyboard, entered commands, and worked with applications built using products such as dBASE, FoxPro, Paradox, and Clipper. These were serious business development tools, not toys. Many developers, including myself, spent years building applications with them.
Then Windows changed the expectations of computer users. Businesses began to want graphical software with windows, buttons, menus, dialog boxes, and mouse support. Companies still depended on their existing DOS applications, however, so developers needed to support the transition without abandoning the systems that businesses already relied upon.
That was not always an easy process. Some DOS programs could continue to run without major changes, but converting an older text-based application into a polished Windows application required time and effort. Developers had to redesign screens, adjust reports, preserve existing program behavior, and often retrain users.
The established database products did eventually produce Windows versions. However, Access had an advantage because it was designed from the beginning as a Windows product. Microsoft Access did not have an older DOS product line that it needed to support, maintain, or carefully transition into a Windows environment. That gave it a different starting point from products that had long histories in the DOS marketplace.
The original video is also correct that pricing helped Access. Access was introduced with a $99 introductory price, which made it much easier for people to try compared with many competing database products at the time. That was not its permanent price, but it was an effective way to encourage people to give Access a chance.
Later, Access became part of Microsoft Office Professional. It was not included in every Office edition, and it was not bundled with the original standalone release of Access. Still, once businesses were already purchasing Word, Excel, PowerPoint, and other Office applications, having Access included in the package was a major advantage.
That was how I personally started with Access. I received it as part of Microsoft Office along with Word, Excel, and PowerPoint. I saw this additional program called Access and decided to find out what it could do. Many people had a similar experience.
Microsoft's timing, pricing, and distribution clearly helped Access become popular. However, popularity alone does not prove that a product was technically superior, and it certainly does not prove that it was technically inferior. We need to consider what people were actually building and what they needed their software to accomplish.
One of the main technical points raised in the original video is that FoxPro was faster than Access in certain situations. FoxPro had genuine strengths in data processing and query performance. That is worth recognizing. Speed matters. Nobody wants to wait unnecessarily for a query to run or for a form to open.
However, a database application is usually more than a query. A business needs a way to enter orders, maintain customer information, print invoices, generate reports, automate repetitive tasks, and give employees a practical interface they can use every day. When comparing tools, we need to compare the whole application development process, not just the performance of one operation.
Suppose one product can run a particular query more quickly, but another product makes it easier to create an order entry form, print an invoice, produce a monthly report, and allow a non-programmer to make a routine change. Which one is better for that business?
The answer depends on the business, the users, the scale of the data, the number of people using the system, and the resources available to maintain it. A fast query is important, but it is not the entire application.
Consider a simple order entry system for a fictional company called Orion Traders. Customer information might be stored in one table, while orders are stored in another. A relationship connects each order to the appropriate customer, which prevents employees from having to type the same customer details repeatedly for every sale.
A query can retrieve the orders needed for a particular task and calculate totals. That handles the data side of the system.
But someone still needs to use the application. An employee needs a form that lets them select a customer and enter an order. The business needs a report that turns the order information into an invoice. Users may also need buttons that automate common actions, such as opening the appropriate report without requiring the employee to remember a sequence of steps.
Access provides tables, queries, forms, reports, macros, and VBA automation in one environment. A developer can begin with built-in designers and add programming as the application becomes more sophisticated. That is a major part of Access's value.
The real question is not simply which product can process a query faster. The question is how much work it takes to turn a business problem into a working solution that employees can use effectively.
The same issue applies after the original application is completed. Suppose the owner of Orion Traders wants a report next month showing customers who have not placed an order recently. Someone needs to create the query, format the report, and make it easy for staff members to run it.
Maintenance, changes, reporting, usability, and development time all matter. The original discussion of Access focuses heavily on pricing and distribution, but those practical application development issues also deserve attention.
There were developers who selected Access early on because they liked what it could do. Luke Chung of FMS wrote about his experiences with Access after having developed products for Paradox. He described being impressed by Access's table design, relationships, queries, forms, reports, and the way those features worked together.
That is not proof that Access was better than every competing product in every circumstance. However, it is a useful firsthand perspective from someone who knew other tools and saw practical advantages in Access. FMS went on to build a significant business around Access products and services, so the low introductory price was not the only reason developers and businesses chose Access.
The competing products deserve credit as well. FoxPro had strong data processing capabilities. dBASE had an influential language and a large developer community. Paradox was a capable database development system. Clipper was also important, although it needs to be understood in its proper context.
Clipper was a compiler and development environment associated with the dBASE language. A compiler takes a program and turns it into an executable application that can run on its own. It was not simply another interchangeable database engine. These products differed in their languages, development methods, deployment models, data engines, and application design tools.
I used several of these products before I began using Access in 1994. I am not suggesting that nothing useful existed before Access. Far from it. Developers created serious and successful business systems with these tools. My point is simply that we can recognize their strengths while still understanding why a developer might choose Access for a particular project.
We also need to be careful with historical timelines. The original video discusses Microsoft's acquisition of Fox and FoxPro's Rushmore technology in a way that can make it sound as though Rushmore was part of Access when Access 1.0 launched in 1992.
Rushmore was FoxPro query optimization technology. In practical terms, it helped improve the speed of locating records for certain types of queries.
Microsoft announced Access availability on December 16, 1992. Contemporary Byte magazine coverage of Access 2.0 in April 1994 described Microsoft adding FoxPro's Rushmore technology to improve set query performance over Access 1.1. That means Rushmore was an Access 2.0 improvement, not part of the original Access 1.0 release.
That distinction matters because we should evaluate each product based on the version available at the time. Giving Access 1.0 a feature that did not arrive until Access 2.0 changes the historical comparison.
FoxPro deserves credit for Rushmore technology. Access also deserves to be judged as it improved over time rather than treating every Access version as though it were identical. Early Access had limitations. I would not describe Access 1.0 as a great piece of software, and even Access 2.0 had plenty of room for improvement. But early versions could still perform useful work, and the product continued to develop.
The original video also presents the discontinuation of FoxPro as though Microsoft acquired it primarily to make Access dominant. That is an interpretation of Microsoft's motive, and it requires more evidence than simply observing that Microsoft acquired Fox and later discontinued Visual FoxPro.
Microsoft acquired Fox in 1992. FoxPro did not disappear immediately afterward. Visual FoxPro 9.0 was released in 2004, and extended support did not end until January 2015. That is a long period of continued development and support.
Microsoft did incorporate useful FoxPro technology into other products, including Access. It is reasonable to conclude that Microsoft eventually decided to consolidate its development efforts. Companies make those kinds of decisions all the time. However, unless Microsoft has provided a documented statement explaining its exact motives, we should distinguish between verified events and our interpretations of why those events occurred.
That does not lessen the disappointment experienced by developers who depended on FoxPro. Many people invested years into that platform and built successful businesses around it. Their frustration is understandable. But historical accuracy still matters.
The same caution applies when discussing Access today. Defending Access does not mean that I recommend it for every possible database project.
If you are choosing a system today, you should consider the amount of data involved, the number of simultaneous users, the security requirements, the expected growth of the application, and the platforms where the system needs to run. Those practical requirements matter much more than winning an argument about which database product has the best reputation.
For some projects, SQL Server is a better place to store the data. That does not mean Access must be discarded. Access can serve as a front end connected to SQL Server tables. Users can continue working with familiar Access forms, reports, queries, and VBA automation while SQL Server handles the data storage and server-side responsibilities.
This combination can be an excellent solution. Access is often criticized for limitations that really apply only when it is being used as both the front end and the back end in situations where a server database would be more appropriate. When Access is used as the front end with SQL Server handling the data, it can provide a very capable business application platform.
Of course, moving tables to SQL Server does not automatically solve every performance, security, or design problem. The application still needs to be designed, tested, maintained, and deployed properly. Slow queries can still be slow. Poor security decisions can still create problems. The architecture has to fit the needs of the business.
The important point is that Access does not have to be viewed as an all-or-nothing choice. Different components can be used for different parts of the solution. SQL Server can manage the data, while Access provides forms, reports, automation, and a user interface that employees can work with efficiently.
Returning to the original video, I agree with its broad historical argument. Windows, introductory pricing, and Office distribution absolutely helped Access become successful. The established competitors faced genuine challenges as the market moved from DOS to Windows.
Where I disagree is with the "worst database" label and the impression it may create about Access today. For the types of business applications I build and teach, Access remains my first choice. Its combination of database features, user interface design tools, reporting capabilities, and automation options remains valuable.
Popularity does not prove technical superiority. At the same time, a faster query in another product does not settle the entire comparison. We need to look at what is being built, what users need, how quickly a solution can be developed, how easily it can be maintained, and whether it can grow with the business.
That is how we can have a useful conversation about which tool is appropriate for a particular job.
You can find a complete video tutorial with step-by-step instructions on everything discussed here on my website at the link below. Live long and prosper, my friends. Topic List Why Microsoft Access became successful
Windows, pricing, and Office distribution
Access compared with dBASE, FoxPro, and Paradox
Evaluating databases beyond query speed
Building forms, reports, and automation in Access
Access as a business application development tool
Maintaining and modifying Access applications
Rushmore technology and Access history
Microsoft's FoxPro acquisition and discontinuation
Using Access with SQL Server back ends
Choosing Access based on application requirements Article Calling Microsoft Access the worst database is not supported by the full history or by the kinds of applications people actually build with it. Access succeeded partly because of timing, pricing, and Microsoft's distribution power, but it also succeeded because it gave users a practical way to build complete business applications in one environment.
When Access arrived, many businesses were already using database products such as dBASE, FoxPro, Paradox, and Clipper. These were serious tools with large developer communities and many real-world applications behind them. They were especially common during the era when most business software ran under DOS.
The shift from DOS to Windows changed what users expected. Businesses wanted graphical screens, buttons, mouse support, printed reports, and applications that felt at home in Windows. Existing database products had to adapt while continuing to support customers who had years of old code, screens, reports, and business processes built around their earlier systems.
Access had an advantage because it was designed as a Windows product from the start. It did not have the same burden of maintaining an older DOS-style application environment. That did not automatically make Access technically superior in every area, but it made it easier for Microsoft to offer a database tool that matched the new Windows experience.
Pricing also mattered. Access launched at a low introductory price compared with many competing database products. That made it easier for businesses, developers, and hobbyists to try it. Later, Access became available as part of certain Microsoft Office packages. If a company was already buying Word, Excel, and PowerPoint, getting Access as part of the same package made it an obvious product to explore.
However, distribution alone does not explain why Access remained useful for so long. The more important question is what users could build with it.
A database application is not just a collection of tables and fast queries. A real business needs employees to enter orders, look up customers, print invoices, review sales activity, and produce reports. Someone has to build the screens that employees use, connect those screens to the data, create printed documents, and make common tasks easy to perform.
Access brings several important tools together in one product. It provides tables for storing data, queries for retrieving and calculating information, forms for entering and viewing records, reports for printing and presenting information, and automation tools for streamlining routine tasks. This combination is one of Access's greatest strengths.
Consider a simple order-entry system. A business might store customers in one table and orders in another. Each order is related to a customer, so employees do not need to repeatedly type the same customer name, address, phone number, and other details every time a sale is made.
A query can combine customer and order information, calculate totals, identify overdue orders, or show sales for a particular period. But a query by itself is not enough for most employees. Staff members need a form where they can choose a customer, enter items, set quantities, and save the order. The business may also need an invoice report that can be printed or sent to a customer.
Access makes it possible to build all of those parts together. A developer can create the tables, define relationships, build queries, design forms, create reports, and add automation so users can perform tasks by clicking buttons. As the application grows, programming can be added to enforce business rules, validate data, automate repetitive work, and guide users through more complex processes.
This is why comparing database products only by query speed can be misleading. Speed matters, especially when applications handle large amounts of data or many simultaneous users. Nobody wants a system where every search, form, or report takes a long time to open. But performance is only one part of the decision.
A tool that runs one type of query faster may still require more effort to create forms, reports, menus, data-entry screens, and printed documents. Another tool may be slightly slower in a particular operation but allow a business application to be built, changed, and maintained more easily. The best choice depends on the needs of the organization.
The original competitors each had strengths. FoxPro was well known for fast data processing and efficient query optimization. dBASE had a major influence on database programming and helped establish a widely used language and development style. Paradox was also a capable database development environment. Clipper was closely associated with the dBASE language and allowed developers to compile applications into programs that could be distributed to users.
These products were not interchangeable, and each had different strengths in database design, programming, deployment, and performance. It is entirely reasonable to recognize that some of them were faster or more mature than early Access in certain areas. It is also reasonable to recognize that Access offered a powerful and approachable way to build full business applications.
Historical comparisons also need to be careful about timelines. Microsoft acquired Fox Software in the early 1990s. FoxPro included a query optimization technology known as Rushmore, which helped improve the process of finding records efficiently. That technology later influenced improvements in Access. It should not be treated as though it was part of Access from its original release, because that changes the historical comparison.
Likewise, it is too simplistic to say that Microsoft acquired FoxPro and immediately eliminated it in order to make Access dominant. FoxPro continued as a Microsoft product for many years after the acquisition. Microsoft eventually ended development and support, but assigning a single motive to that decision requires evidence. Companies often consolidate products, reuse technology across product lines, and shift development resources based on changing markets. Developers who depended on FoxPro had valid reasons to be disappointed, but the product's history is more complicated than a simple takeover story.
The same balanced approach applies to Access today. Access is not the right choice for every database project. If an organization needs to store very large amounts of data, support many concurrent users, provide strong centralized security, run through a web browser, or serve users across many locations, a server-based database may be more appropriate.
Microsoft SQL Server is a common example. It can store data centrally, handle larger workloads, and provide security and administration features that are important in larger organizations. But choosing SQL Server does not mean Access must be discarded.
A very effective design can use Access as the front end and SQL Server as the back end. In this arrangement, SQL Server stores the tables and manages the data, while Access provides the forms, reports, queries, menus, and user interface. Employees can continue using familiar Access screens while the database server handles the heavier data-management work.
This approach still requires planning. Moving tables to a server does not automatically fix poorly designed queries, inefficient forms, weak security practices, or bad application logic. The developer must design queries appropriately, manage connections carefully, secure the database properly, and test the application under real working conditions. But Access and SQL Server can work together extremely well when used for the jobs each does best.
The most useful way to evaluate Access is to begin with the actual problem. Consider how much data will be stored, how many people will use the system at the same time, what kind of security is required, whether users need access from different locations, and how often the application is likely to change.
For a small or medium-sized business application, Access can be an excellent choice. It is especially strong when users need custom forms, printable reports, rapid development, and the ability to make changes without rebuilding an entire system from scratch. It allows a developer to move from a business idea to a usable application quickly.
For larger systems, Access can still be valuable as part of a broader solution. It can serve as a front end for server-based data, provide reporting and data-entry tools, and allow departments to build specialized applications without requiring a full enterprise software project.
Popularity does not prove that a product is technically best in every situation. Likewise, superior performance in one benchmark does not prove that a product is best for every business. The real question is whether the tool helps build an application that meets the needs of its users.
Access became successful because Microsoft placed it in a favorable market position, priced it aggressively, and distributed it widely through Office. But it also became successful because people could use it to build practical applications. Its combination of tables, relationships, queries, forms, reports, and automation gave businesses a way to create systems that employees could actually use every day.
A fair comparison should include performance, but it should also include development time, ease of maintenance, user experience, reporting needs, integration options, security requirements, and the effort required to adapt the application when the business changes. When those factors are included, Microsoft Access is not the worst database. It is a practical development tool that remains useful when matched to the right kind of project. Primary Topics
Access market history, Windows transition from DOS, Access pricing and Office bundling, Access versus dBASE FoxPro Paradox and Clipper, integrated database application development, FoxPro Rushmore query optimization timeline, FoxPro discontinuation inter Secondary Topics
business application usability, forms reports queries automation, development time, database selection criteria, front-end and back-end architecture, historical product maturity |
