D-Base versus Access

[DS]

Does anyone have any thoughts on D-Base? Can it hold more data than
Access? Is it easier to maintain? Is it more flexible? Just wondering
at the end of the year!
DS

 

[Larry Linson]

Does anyone have any thoughts on D-Base?

dBase was, without question, one of the most popular DOS databases (it was
not exactly 'relational'), and was brought into Windows. I never used either
DOS or Windows versions. For a long time, dBase .DBF files were a very
common format for exchanging data. Thus, I've used .DBF files, but never
dBase itself, and I don't waste time and energy contemplating it.

For information on the specs, you should find dBase's own website -- search
for it; Access objects and data, by default are stored in Jet .MDB database
files, which can hold 2GB, plus the Access database can be linked to tables
in multiple Jet .MDBs. I've heard of people using 10GB or more, but with a
file-server database such as Access/Jet, you'd need to consider the extra
cost of restoring should corruption occur. I think you have similar
considerations with dBase, perhaps even more so, because a dBase application
would have a .DBF file for each of its Tables, whereas an Access database
keeps all its objects within the .MDB and linked .MDBs.

My understanding of "Is dBase easier to maintain than Access?" is "No." and
of "Is dBase more flexible than Access?" is "No."

Larry Linson
Microsoft Access MVP

 

[Tom Lake]

My understanding of "Is dBase easier to maintain than Access?" is "No." and

of "Is dBase more flexible than Access?" is "No."

I find the DOS and early Windows versions of dBase much easier to write
than Access. It uses a procedural language, not all the fancy GUI stuff.
For me, that's much easier than event-driven programming.

Tom Lake

 

[Jeff Boyce]

Tom

And I'll offer an opposite opinion... I find the event-driven model much
easier to develop in than a strictly procedural language. And the "fancy
GUI stuff" is what makes Access such a joy, since the user ends up with a
much richer environment.

--
Regards

Jeff Boyce
Microsoft Office/Access MVP


Microsoft IT Academy Program Mentor
http://microsoftitacademy.com/

Microsoft Registered Partner
https://partner.microsoft.com/

 

[John Nurick]

And I'll offer an opposite opinion... I find the event-driven model much
easier to develop in than a strictly procedural language. And the "fancy
GUI stuff" is what makes Access such a joy, since the user ends up with a
much richer environment.

Once in a while I still miss the old dot prompt ... but then I think
what life would be like without SQL and engine-level relational
integrity and validation!

 

[DS]

dBase was, without question, one of the most popular DOS databases (it was
not exactly 'relational'), and was brought into Windows. I never used either
DOS or Windows versions. For a long time, dBase .DBF files were a very
common format for exchanging data. Thus, I've used .DBF files, but never
dBase itself, and I don't waste time and energy contemplating it.

For information on the specs, you should find dBase's own website -- search
for it; Access objects and data, by default are stored in Jet .MDB database
files, which can hold 2GB, plus the Access database can be linked to tables
in multiple Jet .MDBs. I've heard of people using 10GB or more, but with a
file-server database such as Access/Jet, you'd need to consider the extra
cost of restoring should corruption occur. I think you have similar
considerations with dBase, perhaps even more so, because a dBase application
would have a .DBF file for each of its Tables, whereas an Access database
keeps all its objects within the .MDB and linked .MDBs.

My understanding of "Is dBase easier to maintain than Access?" is "No." and
of "Is dBase more flexible than Access?" is "No."

Larry Linson
Microsoft Access MVP

Great Answer! I think I leave D-Base in the box!
DS

 

[Larry Linson]

I find the DOS and early Windows versions of dBase
much easier to write than Access. It uses a procedural
language, not all the fancy GUI stuff. For me, that's
much easier than event-driven programming.

I used procedural languages (e.g., assembler) starting in 1958, and
problem-oriented-languages (e.g., Fortran, PL/1, COBOL, BASIC) starting
sometime in the 1960s. My first experience with "event-driven" was in the
1970s on the IBM Series/1 minicomputer.

Because all the applications I now do are very much involved with user
input, update, and reporting, I find the event-driven model appropriate. If
I were doing math calculations called by other programs, or database
retrieval (I've done a roll-your-own database or few, in my time), the
procedural or POL model might be more appropriate.

And, I have a number of colleagues and associates who make excellent use of
Access with no programming at all... try that with a procedural language
database or language. They just point and click their way to a
user-friendly interface and the built-in functionality makes the Forms work
just fine without code.

I had one colleague who created a rather large application for ordering,
tracking, and inventorying food and supplies for the food service operation
of a major metropolitan school district. He said the only VBA code in that
application was generated by the Wizards. But, hey, it was only their
mainstay application for around ten years. (Oh, and it replaced a dBase
application that he'd written for them a few years earlier, so it's not
because he couldn't program. He is a Mechanical Engineer, and just got
"drafted" for database work by the school district for which he worked.)

However, if you like dBase, there's an OpenSource project called xHarbour
that is dBase compatible and enhanced. Search for it -- you may find it is
just what you want, and, of course, "free" is a really good price. If you
want the point-and-click kind of interface, you may have to pay for an
add-in / add-on.

Larry Linson
Microsoft Access MVP

 

[David W. Fenton]

Once in a while I still miss the old dot prompt ... but then I
think what life would be like without SQL and engine-level
relational integrity and validation!

Didn't later versions of dBase add engine-level RI?

 

[John Nurick]

Didn't later versions of dBase add engine-level RI?

I never worked seriously with anything later than dB IV, so don't know.
But how can you have engine-level RI when each table is stored as a
separate file that other software can access without using the database
engine?

 

[Tom Lake]

I find the DOS and early Windows versions of dBase much easier to

But end users hate that kind of application. I was doing Paradox for
DOS programming back in 1990-94, and what I found was that once
users went to Windows, they hated the DOS database program and
wanted to use the mouse. Yes, it was possible to make Pdox 4 mouse
aware, but it wasn't the same as a GUI. That was the reason I jumped
to Access when I saw it, because it was so easy (in comparison to
Pdox Win).

Maybe your end users hate it but mine love it. Menus are much easier
for them to understand and the mouse is fully functional to click on menu
choices. I created some GUI front ends for them to test and they practically
revolted. Now I have them using Access with a bunch of switchboards and
they're as happy as clams at high tide.

Tom Lake

 

[David W. Fenton]

Maybe your end users hate it but mine love it. Menus are much
easier for them to understand and the mouse is fully functional to
click on menu choices. I created some GUI front ends for them to
test and they practically revolted.

Maybe the problem is that you're not designing good GUI interfaces.

It's not nearly as easy as most people think.

 

[David W. Fenton]

I never worked seriously with anything later than dB IV, so don't
know. But how can you have engine-level RI when each table is
stored as a separate file that other software can access without
using the database engine?

I don't know, but I seem to recall one of the later versions added
engine-level RI (or at least something that qualified as a checkbox
on a feature list and looked like RI).