Microsoft Access 2.0 had filters to import and export data from and to DBF files. We used this in WFW 3.11 to convert from DBase to MS-Access and later on SQL Server.
There were some Turbo C and Turbo Pascal source code that read DBF files, but hardly anyone used them. Most stored data is in text files that can be read by any application.
MS Access can use DBF files almost as if they were standard Access tables. This was particularly useful when working with ESRI Shapefiles, as it allowed the DBF files to be edited in Access and the changes to be viewed directly in ArcGIS. When editing maps, Access was often more convenient than the ESRI Editor.
I started with dBase but quickly moved to foxbase which was much faster. Foxbase was renamed FoxPro when DOS moved to Windows and soon thereafter Microsoft purchased FoxPro. Since FoxPro was a dBase derivative, there were high quality conversion interfaces between Access and FoxPro (and all dBase dialects).
Aside: I was such a fan of Foxbase that the very day Microsoft's acquisition was announced (circa ~1992), I invested $10,000 in Microsoft. I sold maybe 10 years later for $100,000. Stupid Stupid Stupid.
I feel the timeline is wrong re when dBase Inc took over. I remember working as a consultant on shipping new features for dBase back in 2000 or so.
I implemented reflection for the dBase language and was also part of trying to convert it to Visual C++ instead of using the Borland compiler. I was very green back then but it was interesting, my only time dealing with interpreters / compilers
My first gig at 18 was managing my university library's database (in dBase III; it was the 1980s) and writing the user interfaces for searching. This was a pre-SQL database for you youngins in case you have no idea what I'm talking about.
One of my first sizeable projects was a COM-compatible compiled language with .dbf support primitives for data transformation. As a unique quirk, it could even work on Novel Netware to interface with Btrieve.
Netware supported loading PE executables, but it lacked memory protection so developing for it was... fun.
The .dbf format was pretty straightforward, though.
I remember dBASE IV from my childhood days when my father, who had no computer background, was required to take computer training by his workplace. My father and his colleagues were given free evening computer lessons by their company, taught by the same teachers who used to teach us, the kids, computers in our school.
After their first class, he brought home a fat dBASE IV manual. Since I was very interested in computer books, I read a good portion of it even though I had never touched dBASE in my life. I would daydream of all the little forms, queries, reports and labels I could make with dBASE. But I never got to touch dBASE in my life. We kids used to get LOGO lessons instead in school.
One day my father came back from his evening lesson mildly distressed about something he had learnt. He said they were being taught loops but in the loop there was an equation that seemed just plain wrong. It was:
i = i + 1
How could that be a valid equation? How could i ever equal i + 1? He mentioned that he had asked the teacher about it and from what I could gather, my teacher and my father were talking past each other. The teacher probably tried explaining that it was not an equation but an instruction instead, whereas my father continued to interpret i = i + 1 as an equation due to the algebra he was so familiar with. It sort of held up the class for a while.
The teacher asked my father's name, perhaps so that he could talk to him separately later. But when he learnt my father's name, he realised that his son, me, went to the same school where he taught. So he told my father, 'When you get back home, ask your son about i = i + 1. He will explain it to you better than I am able to.'
And indeed I was able to explain it to him pretty well. I was eight or nine years old back then. And that was probably the first thing I taught my father!
One of my favourite DB systems, started with dBase III+ where our teacher made us enter the high-school library records, followed up with Clipper Summer '87, and shortly thereafter Clipper 5.x with its OOP extensions.
Great productivity tool, garbage collected, compiled, in the constrained environment of MS-DOS PCs.
The migration to Windows 3.1 took too much time, giving time to FoxPro, Access, Visual Basic and Delphi to establish themselves to the same programming communities.
Similar to other HNers, Clipper was also how I made my first attempts to working for others during high school.
In 1998 I wrote a financial summary for our ERP system (EUROnet) running on MS DOS with a dBase db in the backend. I've connected the dBase to a PHP 3 web server with Apache 1 and then summarized the sales data. My boss loved it. He could see numbers which are not implemented in the ERP reports.
I find this blog consistently negative (check other posts.) Although this post is interesting, and I know little about dBase and this is a sad story, I am simply not sure how accurate all of the blog as a whole is. I can best suggest, take its statements as someone's personal opinion, not necessarily as fact, ie but with a pinch of salt.
> It is believed that - alongside the BOLD source code (missing for more than 10+ years), the BDE and many original dBase source code was lost during the ill fated Borland + Corel merger (which was eventually called off).
This is confusing because the article is supposedly about dBase, and I have no idea why Bold is relevant. It's an example of where I feel the general negativity of the blog veers into random discussions.
To the best of my knowledge, the Bold source was not lost. In fact, Embarcadero open sourced it several years ago. The blog post has details: https://blogs.embarcadero.com/bold-for-delphi-is-open-source... I worked there at the time though I did not drive its open sourcing, but it is a positive move, and clearly contrasts the blog's statement. It appears actively maintained and updated these days. I would differentiate 'lost' from 'owned but not made available publicly'.
>By feeding legacy PRG (circa 1985) and logics to models like Claude, ChatGPT, developers can now instruct the AI to translate decades-old dBase PRG directly into memory-safe Rust, highly concurrent Go, or modern Dart/Flutter cross-platform applications.
And it alludes to this early on, but it doesn't show any examples.
I still maintain a VFP9 project from time to time.
Although AI has been extremely helpful in writing VFP9 code, I can't imagine migrating this enormous project, which has grown over the course of 30 years, to a more modern system by feeding the source code to AI.
While one could debate which approach would be best for migrating such a project, an 'AI-led Big Bang Migration' would be insane.
However, AI would certainly be helpful for migration.
One of my first jobs had a legacy application that was based on Clipper. I never had to work with it directly (since I worked on the SQL successor) but reading the source code was still fascinating.
I remember my father built its own personal accounting tool using dbase, I think it was MSDOS at the time, I was a kid. Quite the achievement I think, he was not a software engineer, just hobbyist.
Don't forget DataEase [1]. That's what I eventually moved to from dBase (although, IIRC, it was through back-and-forth evaluations of FoxPro, Clipper, and Paradox). DataEase was considered a "Fourth-Generation Language" (4GL) and it was wonderful to work with. As a teenage "systems analyst" working for a division of GE (my first paid tech job), I built a file room management system for their large file rooms (remember those?). Having to thoroughly test security, I put it through its paces and found a way to hack into any application built on DataEase. Eventually explaining the procedure to DataEase's development team (which included one developer traveling to my fraternity house for a face-to-face meeting; so funny trying to be business-like in a place with sticky floors and smelled like stale beer), they fixed the hole. There weren't any bug bounties during those days but, as a reward, they gave me lifetime upgrades and allowed me to go to all their training seminars for free. It was my 4GL experience that ultimately led to learning Cognos.
Funny aside: I remember the first time my GE boss asked me for an invoice as it was the only way he could pay me. I had no idea what it should look like. So he sent me to the PM of one of the COBOL contractor teams who gave me a template that I copied. The PM eventually asked me to do some COBOL programming for them as well. Good times.
One of my trifecta of 'perfect' DOS software: DataEase 4.53, WordPerfect 4.2, and TopSpeed Modula-2. Given the restrictions of the day, all three were incredible.
Shapefiles, the legacy multifile file format for geospatial stuff that is still an incredibly important interchange format since it has basically universal support is built around DBF files.
So despite it being an incredibly old file format it's still used constantly in the GIS world and it's probably not going to go away because while it's not a good format, it does basically everything at to at least a mediocre level which can't be said for any of the newer formats that tend to do a few things great but other things terribly.
Like Geojson is great for interchange but you can't really do in place edits or even in place seeking from disk, shapefile can.
Sqlite allows great editing and seeking but you can't use that in a browser without doing something complicated like compiling the sqlite binary to js or wasm.
37 comments
[ 4.5 ms ] story [ 54.6 ms ] threadThere were some Turbo C and Turbo Pascal source code that read DBF files, but hardly anyone used them. Most stored data is in text files that can be read by any application.
Aside: I was such a fan of Foxbase that the very day Microsoft's acquisition was announced (circa ~1992), I invested $10,000 in Microsoft. I sold maybe 10 years later for $100,000. Stupid Stupid Stupid.
I implemented reflection for the dBase language and was also part of trying to convert it to Visual C++ instead of using the Borland compiler. I was very green back then but it was interesting, my only time dealing with interpreters / compilers
Netware supported loading PE executables, but it lacked memory protection so developing for it was... fun.
The .dbf format was pretty straightforward, though.
Strange it is not cited in the post.
I think the main gist: you work not as app developer but as db developer, is something that is missing in some partial attempt like access and such.
BTW: Wanna join me or help?
After their first class, he brought home a fat dBASE IV manual. Since I was very interested in computer books, I read a good portion of it even though I had never touched dBASE in my life. I would daydream of all the little forms, queries, reports and labels I could make with dBASE. But I never got to touch dBASE in my life. We kids used to get LOGO lessons instead in school.
One day my father came back from his evening lesson mildly distressed about something he had learnt. He said they were being taught loops but in the loop there was an equation that seemed just plain wrong. It was:
How could that be a valid equation? How could i ever equal i + 1? He mentioned that he had asked the teacher about it and from what I could gather, my teacher and my father were talking past each other. The teacher probably tried explaining that it was not an equation but an instruction instead, whereas my father continued to interpret i = i + 1 as an equation due to the algebra he was so familiar with. It sort of held up the class for a while.The teacher asked my father's name, perhaps so that he could talk to him separately later. But when he learnt my father's name, he realised that his son, me, went to the same school where he taught. So he told my father, 'When you get back home, ask your son about i = i + 1. He will explain it to you better than I am able to.'
And indeed I was able to explain it to him pretty well. I was eight or nine years old back then. And that was probably the first thing I taught my father!
Great productivity tool, garbage collected, compiled, in the constrained environment of MS-DOS PCs.
The migration to Windows 3.1 took too much time, giving time to FoxPro, Access, Visual Basic and Delphi to establish themselves to the same programming communities.
Similar to other HNers, Clipper was also how I made my first attempts to working for others during high school.
> It is believed that - alongside the BOLD source code (missing for more than 10+ years), the BDE and many original dBase source code was lost during the ill fated Borland + Corel merger (which was eventually called off).
This is confusing because the article is supposedly about dBase, and I have no idea why Bold is relevant. It's an example of where I feel the general negativity of the blog veers into random discussions.
To the best of my knowledge, the Bold source was not lost. In fact, Embarcadero open sourced it several years ago. The blog post has details: https://blogs.embarcadero.com/bold-for-delphi-is-open-source... I worked there at the time though I did not drive its open sourcing, but it is a positive move, and clearly contrasts the blog's statement. It appears actively maintained and updated these days. I would differentiate 'lost' from 'owned but not made available publicly'.
>By feeding legacy PRG (circa 1985) and logics to models like Claude, ChatGPT, developers can now instruct the AI to translate decades-old dBase PRG directly into memory-safe Rust, highly concurrent Go, or modern Dart/Flutter cross-platform applications.
And it alludes to this early on, but it doesn't show any examples.
While one could debate which approach would be best for migrating such a project, an 'AI-led Big Bang Migration' would be insane.
However, AI would certainly be helpful for migration.
They could have still been the king of the hill now if it weren't for the suits who completely ruined it after Philippe Kahn left the scene.
Semi off-topic: The wikipedia article on Ed Esber is in dire need of a clean up https://en.wikipedia.org/wiki/Ed_Esber
Funny aside: I remember the first time my GE boss asked me for an invoice as it was the only way he could pay me. I had no idea what it should look like. So he sent me to the PM of one of the COBOL contractor teams who gave me a template that I copied. The PM eventually asked me to do some COBOL programming for them as well. Good times.
[1] https://www.dataease.com/
So despite it being an incredibly old file format it's still used constantly in the GIS world and it's probably not going to go away because while it's not a good format, it does basically everything at to at least a mediocre level which can't be said for any of the newer formats that tend to do a few things great but other things terribly.
Like Geojson is great for interchange but you can't really do in place edits or even in place seeking from disk, shapefile can.
Sqlite allows great editing and seeking but you can't use that in a browser without doing something complicated like compiling the sqlite binary to js or wasm.