What Happened to Dbase?
What Happened to DBase?
If you were involved with personal computers in the 1980s or early 1990s, there is a good chance that somebody, somewhere, was running dBase.
It may have been in a small business keeping track of customers. It may have been in a local authority recording dog licences. It may have been in a doctor’s surgery. It may even have been lurking in the corner of a multinational corporation doing something so important that nobody dared switch the machine off. Somewhere in a dusty office, next to a beige filing cabinet and a pot plant that had died during the Thatcher administration, dBase was quietly getting on with the job.
Today, however, dBase occupies a strange place in computing history. It is neither celebrated in the way that Windows, Linux or the Macintosh are celebrated, nor is it remembered with quite the same affection as the Sinclair Spectrum, Commodore 64 or Amiga.
Instead, dBase has become one of those technologies that provokes a reaction along the lines of:
“Blimey, I’d forgotten about that.”
And yet at one point it was one of the most influential software products in the world.
So what happened to dBase?
The answer involves corporate intrigue, legal battles, changing technology, changing expectations, some extraordinarily poor timing, and enough business mistakes to keep MBA students entertained for decades.
It is also a cautionary tale about how being the king of a market today does not guarantee you’ll even be invited to tomorrow’s party.
In the Beginning
To understand dBase, we need to return to a period when computers were considerably simpler, considerably slower, and considerably less likely to demand a subscription fee every month.
The story really begins with a product called Vulcan.
In the late 1970s, a software developer named Wayne Ratliff created a database program for CP/M systems. CP/M was the operating system of choice before IBM PCs arrived and changed everything.
Vulcan was inspired by an earlier mainframe database system called JPLDIS and was intended to make data management easier on microcomputers.
This may not sound exciting.
Indeed, “database management” ranks somewhere below “watching paint dry” and somewhere above “reading insurance policy exclusions” on most people’s excitement scale.
However, in the business world, databases are gold.
Businesses run on information. Information means records. Records need storing. Storing them in paper folders works until somebody puts the folder somewhere “safe” and nobody ever sees it again.
Computers offered something different.
A properly designed database could retrieve information quickly, sort it, search it and generate reports.
To a business owner in 1980, this looked remarkably like magic.
Ashton-Tate Arrives
Enter Ashton-Tate.
Founded by George Tate and Hal Lashlee, Ashton-Tate acquired the rights to market Ratliff’s software.
The product was renamed dBase II.
Observant readers may immediately notice something odd.
Why dBase II?
What happened to dBase I?
Nothing.
There wasn’t one.
The company believed version II sounded more mature and established.
Apparently software marketing departments were already discovering that customers trusted version two more than version one.
This tradition survives today.
Somewhere, somebody is probably launching AI Product 4.0 despite AI Product 1.0 never existing.
Regardless of numbering creativity, dBase II became a huge success.
Released in 1980, it arrived at exactly the right moment.
The personal computer revolution was beginning.
Businesses were buying PCs.
Those PCs needed useful software.
dBase provided exactly that.
The Killer Application Nobody Talks About
When people discuss early business computing, spreadsheets usually get all the glory.
Programs like VisiCalc and later Lotus 1-2-3 are often credited with driving PC adoption.
That is true.
But databases were equally important.
Imagine running a business with several thousand customers.
You need names, addresses, purchase histories, invoices and reports.
Before databases, much of this involved filing cabinets and administrative staff.
dBase changed that.
It allowed ordinary businesses to build custom applications without employing a team of programmers.
In effect, dBase became a platform as much as a product.
People weren’t simply using dBase.
They were building systems with dBase.
Entire businesses became dependent upon it.
Many users never even saw dBase itself. They saw a bespoke application written by somebody who understood dBase commands.
This flexibility became one of its greatest strengths.
And eventually one of its greatest weaknesses.
The Rise to Dominance
Throughout the 1980s, dBase expanded rapidly.
dBase III arrived in 1984.
Then dBase III Plus.
Then dBase IV.
Each version added features and capabilities.
By the mid-1980s Ashton-Tate was one of the largest software companies in the world.
The numbers were staggering.
Millions of users.
Hundreds of thousands of developers.
Entire ecosystems of books, consultants and training courses.
Being a dBase developer was a legitimate career path.
Bookshops devoted shelf space to dBase manuals.
Not one shelf.
Entire sections.
Young people today may find this difficult to comprehend.
There was a time when a 700-page database programming manual was considered an exciting purchase.
People voluntarily bought these things.
Some even read them.
The Clone Wars
Success attracts competition.
Competition arrived with remarkable enthusiasm.
Because dBase was so popular, other companies started creating compatible products.
Among the most notable were:
- Clipper
- FoxBASE
- FoxPro
- Nantucket Clipper
- Quicksilver
The key idea was compatibility.
If your software worked with dBase files, users could switch without starting from scratch.
This became increasingly important because Ashton-Tate was beginning to make mistakes.
Quite a lot of mistakes.
In fact, if software companies received points for poor strategic decisions, Ashton-Tate would have been challenging for the championship.
The dBase IV Disaster
Ask long-time database users what happened to dBase and many will point directly at dBase IV.
Released in 1988, dBase IV should have cemented Ashton-Tate’s dominance.
Instead, it became legendary for the wrong reasons.
The software was late.
It was slow.
It was buggy.
It required substantial hardware resources by the standards of the day.
Users who upgraded often discovered that things which worked perfectly in earlier versions now behaved unpredictably.
This was not ideal.
Businesses generally prefer database systems that do not suddenly decide to behave unpredictably.
Particularly when payroll is involved.
The launch was so problematic that competitors sensed blood in the water.
And competitors were often producing products that were faster, cheaper and more reliable.
That is rarely a combination you want your rivals to possess.
The Legal Strategy That Backfired
At around the same time, Ashton-Tate became increasingly aggressive in defending its intellectual property.
The company pursued legal action against competitors creating dBase-compatible products.
From a certain perspective this made sense.
They wanted to protect their market.
Unfortunately, customers often saw things differently.
Developers liked compatibility.
Businesses liked compatibility.
The ecosystem liked compatibility.
Trying to prevent compatibility was rather like trying to stop people using standard screws because you invented one particular screwdriver.
It generated resentment.
More importantly, it distracted the company from improving its own products.
History repeatedly demonstrates that technology firms rarely win by suing competitors into irrelevance.
They win by building better products.
Microsoft Appears
Meanwhile, a small software company called Microsoft was quietly becoming rather important.
You may have heard of them.
As personal computing shifted toward graphical interfaces, Microsoft began shaping the future through Windows.
This created a significant challenge for dBase.
dBase had been born in a text-based world.
A world of command lines and keyboard shortcuts.
Windows introduced different expectations.
Users increasingly wanted graphical interfaces.
Point-and-click interaction.
Buttons.
Menus.
Dialogue boxes.
The entire computing landscape was changing.
Unfortunately, Ashton-Tate seemed reluctant to recognise the speed at which this transformation was occurring.
The FoxPro Threat
One of the most dangerous competitors was FoxPro.
Developed by Fox Software, FoxPro earned a reputation for impressive performance.
Users frequently discovered that FoxPro applications could handle large databases more efficiently than dBase.
Developers appreciated its speed.
Businesses appreciated its reliability.
Managers appreciated not receiving angry telephone calls from staff.
In 1992, Microsoft acquired Fox Software.
This proved enormously significant.
Suddenly dBase was competing not only with a rival database product but with Microsoft’s vast resources and growing influence.
That is rather like discovering your local football team must now play against an entire Premier League squad.
The Borland Chapter
By the early 1990s, Ashton-Tate’s position had weakened considerably.
In 1991 the company was acquired by Borland.
At the time, Borland was itself a major software player, famous for development tools and products such as Turbo Pascal.
The acquisition appeared promising.
Perhaps Borland could revitalise dBase.
Perhaps new leadership could restore momentum.
Perhaps customers would return.
Instead, matters became increasingly complicated.
Borland inherited not only the product but also years of technical baggage and market confusion.
Meanwhile Microsoft continued advancing.
Windows Changes Everything
The transition from DOS to Windows altered software development fundamentally.
In the DOS era, dBase’s strengths were obvious.
Rapid development.
Powerful scripting.
Relatively straightforward deployment.
Under Windows, expectations became dramatically higher.
Users demanded graphical interfaces.
Networking capabilities.
Client-server architectures.
Integration with other software.
Visual development tools.
The world was moving beyond simple desktop databases.
Organisations increasingly wanted enterprise systems.
The market was changing faster than dBase could adapt.
Enter Microsoft Access
Perhaps no single product symbolises dBase’s decline more effectively than Microsoft Access.
Introduced in the early 1990s, Access was not necessarily superior in every technical respect.
Indeed, many veteran database developers would happily spend several hours explaining precisely why it wasn’t.
Sometimes several days.
However, Access possessed something more important.
It was part of Microsoft’s ecosystem.
It integrated naturally with Windows.
It worked alongside Word and Excel.
It looked modern.
Most importantly, it felt like the future.
Businesses buying Windows PCs increasingly saw Access as the obvious choice.
Not because it was perfect.
Because it was there.
Never underestimate the commercial power of being the thing already installed on the computer.
The Database Market Evolves
Another challenge emerged from above.
While desktop databases were fighting amongst themselves, larger database systems were becoming increasingly powerful.
Products such as Oracle Database and Microsoft SQL Server targeted enterprise customers.
Meanwhile open-source alternatives would later gain traction.
The centre of gravity shifted away from standalone desktop databases.
Organisations wanted networked systems.
Shared access.
Central servers.
Scalability.
dBase’s original architecture increasingly reflected assumptions from an earlier era.
It wasn’t obsolete.
But it was no longer defining the future.
The Curse of Success
Ironically, one reason dBase survived for so long was precisely why it struggled to evolve.
There were too many existing applications.
Too many users.
Too many legacy systems.
Too much compatibility to maintain.
Every change risked breaking something.
Every improvement risked upsetting customers.
This is a common problem in technology.
Successful products accumulate history.
History accumulates complexity.
Complexity slows innovation.
Meanwhile newcomers arrive with fewer constraints.
They build cleaner systems.
They move faster.
They attract new customers.
The cycle repeats.
Did dBase Actually Die?
Not quite.
This is where the story becomes interesting.
Many people assume dBase disappeared entirely.
It did not.
The product continued evolving through various ownership changes.
New versions appeared.
Dedicated communities remained.
Businesses continued running applications.
In some sectors, systems built decades earlier remained operational.
The remarkable thing about databases is that if they continue doing their job, organisations often leave them alone.
A database application written in 1994 that still works perfectly can survive far longer than fashionable technologies that generated headlines but delivered little practical value.
Some dBase systems have probably outlasted several generations of management consultants.
This is no small achievement.
The Legacy of dBase
Even though dBase lost its dominance, its influence remains enormous.
Many concepts we now take for granted became popular because of dBase.
Rapid application development.
End-user programming.
Database scripting.
Custom business applications.
Developer ecosystems.
The notion that ordinary organisations could build software tailored to their own requirements owes much to dBase.
Its file formats became industry standards.
Its command structure influenced later products.
Its ideas spread throughout the software industry.
Indeed, one of the peculiar aspects of computing history is that technologies often disappear precisely because they succeed.
Their ideas become absorbed into everything else.
The original product fades.
The concepts survive.
Lessons from the Fall
Several lessons emerge from the dBase story.
First, market leadership is temporary.
No matter how dominant a company appears, technology changes.
Customer expectations change.
New competitors emerge.
Second, compatibility cuts both ways.
It creates ecosystems and customer loyalty.
It can also make adaptation painfully difficult.
Third, legal battles rarely compensate for product weaknesses.
Customers generally prefer innovation over litigation.
Fourth, timing matters enormously.
dBase’s difficulties coincided with one of the most significant transitions in computing history: the move from DOS to Windows.
Few companies navigated that transition perfectly.
Finally, success itself can become a burden.
The larger a platform becomes, the harder it is to reinvent.
Conclusion
So what happened to dBase?
The short answer is that it became a victim of technological change, competitive pressure, strategic mistakes and shifting customer expectations.
It dominated the database world during the 1980s.
It helped define business computing.
It enabled countless organisations to computerise their operations.
It created careers, companies and software ecosystems.
Then the world changed.
Graphical interfaces replaced text screens.
Client-server systems replaced standalone databases.
Microsoft became dominant.
Enterprise databases expanded.
New development tools emerged.
And dBase gradually moved from centre stage to the wings.
Yet describing dBase as a failure would be profoundly unfair.
Most software products would regard dBase’s history as a dream.
It helped shape an industry.
It influenced generations of developers.
It remained useful for decades.
It solved real problems for real businesses.
And, perhaps most impressively of all, there are probably still machines somewhere quietly running dBase applications today.
Hidden in back offices, warehouses and local businesses, faithfully performing tasks nobody has dared migrate because the system still works.
There is something wonderfully reassuring about that.
In a technology industry obsessed with the next big thing, dBase serves as a reminder that sometimes the greatest compliment software can receive is not excitement, innovation or publicity.
It is simply this:
“Leave it alone. It still works.”
For a database program born when disco was still a serious cultural force, that is not a bad epitaph at all.
#databases #dbase #history #tools