10: If I correctly understand your answers to the previous
questions, there's no (built-in) report generation, no
forms-based entry, no GUI interface, and no support for
SQL. I can't imagine why you wasted your
time writing this. Is
there any way in which ADB can best a traditional DBMS such
as Access, FoxPro, Paradox, etc.?
Yes. Here are the "top 10."
ADB and all its utilities are freeware.
(That includes the source code for everything except the
two items that I didn't write--GNU Awk and Robert Pirko's
RPSort.Com).
That means that anyone or any organization can use them
anytime, and on any number of computers--without licensing
issues.
And if that's not enough: ADB and all its utilities take
up much less than a megabyte. To "install" ADB on another
machine, you just add one line in C:\Config.Sys, one line
in C:\AutoExec.Bat, and then you copy all the executables
to C:\Windows\Command. What could be
simpler? (Actually
the process is slightly different for NT, but the idea is
the same.)
ADB's processes can be integrated very easily with
standard DBMSs--as well as with
application-specific
executables.
ADB has no proprietary data storage format.
And because everything's in plain text, you can easily mix
your own executables or Perl Scripts (etc.) with ADB
processes.
Unlike standard DBMSs, you can import "global application
data" into ADB's awk scripts.
And you can do so without creating a special table and/or
using obscure or inelegant SQL
constructs . . . or worse,
having to undertake extensive manual modifications every
time something changes (e.g., a sales tax rate.)
Awk also lets you export global data as well, with its
handy "system" function (I show you how to do both the
import and export operations in this documentation).
Because all ADB's data and data structures (e.g. file
layouts) are represented in plain ASC text files which can
be viewed/edited with Windows Notepad (or WordPad), you'll
never again have to hear a client or user tell you that
they "can't open the database."
Nor will you ever have to wait for hours in a telephone
support hold queue, only to finally discover that the
tech. doesn't know what
"APPLICATION ERROR 428-DH53-6820 Rev. 4"
actually denotes.
(That in turn means that you'll have to retrace every
step you undertook and verify all the data as best you
can . . . since
the error message is inscrutable.)
Although plain text data can get "corrupted," it's easy to
gaurd against this by using a simple archiver to make
copies of the files.
Even if you don't have those backup copies, at least
you'll know with certainty what's wrong.
That means you'll be able to distinguish "bad data" from a
mistake in your code (or database
definitions) . . . which
the DBMS manufacturer decided to label as:
"APPLICATION ERROR 428-DH53-6820 Rev. 4".
There's no "hidden" overhead data stored in the Windows
registry or in any other file that can "go out of sync"
(and which can't be fixed except via restoring the entire
database . . . from
corrupt or nonexistent backup files.)
ADB requires very little sophistication to use.
Although it is necessary to be able to "think like a
progammer," the basic concepts needed are: (1) an
understanding of what "file," "field," "record," and "key"
mean; (2) enough Javascript (or C) to be able to code
simple Awk functions; and (3) a little patience when it
comes to understanding how to code DOS batch files
(there's a tutorial here), as well as the utilities (each
prints running instructions when run with no arguments).
Any bright high school student should be able to master
these skills--no $125/hr. consultants are required.
I've gone to great pains to make sure that the main
program (ADB.Exe) provides highly specific error messages,
and there are 8 help screens built right into the program
(type "ADB ?" from the DOS command line). ADB will also
dump all the help screens into a text file from the command
line (another option you get when you run "ADB ?").
ADB's "language" has only
five simple
statements.
Once you've read and understood this documentation, you
should be able to use ADB and all of its utilities from
the DOS command
line . . . without having to constantly
come back here in order to look up "picky details."
ADB's file naming conventions make "off-site debugging" a
snap.
Never again will you have to worry about whether
PC-Anywhere or any such similar product is installed on a
user's or client's computer. (If you've priced
out PC-Anywhere recently, you'll have noticed that it's
near $100 on the "street").
I've included 3 archivers (2 shareware, 1 freeware) in the
distribution package, plus a sample DOS batch file that
uses PkZip (the predecessor to WinZip) to zip up all the
files for an application (so they can be sent as an
e-mail attachment).
ADB's just as compatible (and efficient) on a standalone
286-10 running
DOS 3.1 . . . as it is when running on a
networked P3-700 with NT 4.0 or Windows 2000.
Neither ADB nor any of its utilities use a large number of
file handles, or any "expanded" (DMPI) memory calls, "RAM
residency", or other intricate features of DOS that may
not be supported in the future.
400K of free DOS conventional memory is quite enough to
run any ADB application.
So-o, did you just upgrade your network software for
$250,000 and then discover (surprise!) that you'd be out
another $25,000--because none of your standard DBMS
programs work (or you need a new site license for an
upgrade of the DBMS?).
Not with ADB. Build something in
ADB . . . and it'll be
alive, kicking, and in the best of health when you meet
your maker--for the simple reason that the DOS command
line is here to stay.
ADB takes the concept of "tracing" (AKA "logging") to the
limit.
Those of you who remember (or who still work on)
IBM mainframes will appreciate the virtues of having job
and step names, run time/dates, file I/O counts, and all
the other necessary information needed to follow the
progress of a complex process that has to be run
periodically . . . when
something goes "bump in the
night."
Because ADB applications are built with DOS batch files,
it's trivial to "freeze the processing" and inspect the
temporary files and/or other possibly-flawed transient
data which might be at the root of the problem.
Did a former employee or consultant write a 5,000-line C++
or VB program/system which no longer
works? Hmm. Guess
you'll have to get a copy of the debugger, right? And/or
find someone who knows the language, so that they won't be
wasting their time when "stepping" through the code.
(Bottom line: you can kiss a few thousand dollars goodbye.)
Tracing, as well as the basic simplicity of ADB
applications, in conjunction with the openness of the file
structure and the global
definitions . . . work together
to allow you to get "to the bottom" of the problem quickly
(or to check up on "lazy" users who aren't regularly
running required processes).
And if you need to "mix" application-specific executables
into the "jobstream," they can be a whole lot "cleaner"
(translation: easier to write, debug, and maintain.)
ADB's first and
formost . . . batch.
That means that it
can run in places (e.g. on an NT server) where many DBMS
processes can't. No pointing, clicking, or other user
action is required to initiate ADB operations. Just use
the utility Sleep.Exe to set up the WinTel version of a
Unix "demon" to run forever, as data is collected by
(e.g.) your server's CGI interface.
(It's also worth mentioning that a DOS batch file can be
set up as a Windows Desktop icon, just as any other
program, in the event that the users are being asked to
run processes periodically.)
ADB's fast.
Unlike a traditional DBMS, ADB
batch
processes can be initiated without loading many megabytes
of executable
code . . . and the basic discipline requires
the kind of sorting and matching which minimizes
"non-local" disk "seeks."
This is the same style of I/O which was not only
near-universal, but absolutely required on the older IBM
mainframes (the 360/370 series machines). Keep in mind that
these computers were no faster than a 386-16, and yet they
served large firms with millions of customers. (Caveat:
they did have very highly optimized disk interfaces,
roughly equivalent to today's SCSI, as well as an
extremely efficient product called Syncsort.)
If you've ever noticed that many modern Windows programs
seem to "freeze" for minutes at a time because massive
amounts of memory are being swapped (and sometimes
endlessly re-swapped) to disk,
you'll know exactly what I
mean.
On modern machines, ADB processes can often run
considerably faster than a traditional DBMS for
applications involving less than (say) 500,000 records.
This is not only because ADB's required processing
discipline emphasizes sequential I/O, or even due to the
small size of the executables, but also because ADB (and
all its utilities) are written in optimized "plain
vanilla" C or assembly language, instead of VB--or other
inefficient modern languages that tend to burn up
excessive amounts of resources.
Return
to local table of contents
Return
to global table of contents
Frames mode, or
No frames
11:
So, with ADB, I can throw away my compilers and my standard
DMBSs?
On the contrary.
The whole point of ADB is to have a very simple interface that
can help you manage the basic operations of sorting, matching,
duplicate removal, and the simple "massaging" of fields.
These deceptively straightforward tasks often take up a
disproportionately large amount of code in most complex
applications systems.
The trick to getting the most out of ADB is to try to use the
"right approach for the right (part of the) job."
Think of a traditional compiled programming language as an
elaborate machine shop. Even if you're comfortable with the
machines and can run them yourself, you don't want to "go
there" if all you need is a set of hand tools to change a
spark plug.
Think of a DBMS as a bit like going to your friendly local
automobile dealer. There are a lot of factors that aren't
under your control. Unexpected surprises can result which
could take large amounts of time to disentangle. But if you
have to have their expertise,
then . . . you gotta have it!
Specifically: for those rare applications that require the
full power of SQL, or for generating user forms, you might
just want to stick with your DBMS. That's why ADB has a
convenient import/export facility for commas-n'-quotes
format.
The same goes for reports: some DMBSs or report generating
packages have wonderfully clean and elegant interfaces for
building reports. ADB could help you with some initial
massaging, but perhaps your DBMS or report generator could do
a better job of handling the processing needed to "break"
and/or compute subtotals on several different fields.
For the parts of a complex application that require "true"
random access (i.e. where you really do need to "set cursors"
and/or move backwards and forwards in files), or where you
need intricate and I/O-intensive processing that's done most
efficiently with many input and output files being
simultaneouly
present . . . then you can and should continue
to write code in a standard compiled language (or "4GL").
ADB and its companion utilities can handle a surprising number
of your small and medium sized jobs in a clean and efficient
manner all by themselves (with a little help from GNU Awk).
And by integrating ADB into your larger systems, you can
simplify the design and minimize the amount of SQL and/or
compiled code that you need to write, which in turn makes
these systems faster and easier to debug and develop, as well
as simpler to maintain.
Return
to local table of contents
Return
to global table of contents
Frames mode, or
No frames
12: What about an interface for C++ and/or VB instead of
Awk? And have you considered porting ADB to Unix?
Yes, I've considered writing an interface for
[V]C++--actually
it wouldn't take much work to print out C-style record layouts
and build a few include files with standard functions.
While I'm not a huge fan of VB, I might consider
supporting it on request.
(Personally, I think VB is a woefully
inefficient language by comparison to the C variants, particularly
when it comes to data-intensive applications. And
the size of VB executables is often measured in the megabytes
or tens of megabytes, as opposed to the corresponding C modules,
which might be tens of K. This puts tremendous unnecessary
stress on WinTel OSs. And then there's the fact that the user
needs hundreds of megabytes of DLLs because new VB versions are
released annually. Although
VB is faster to develop than C, it's
just that what you get from the development process burns up
execessive amounts of resources, which is especially bad news
for NT server applications.)
A Unix port would be tricky because the FIELDWIDTHS variable
in GNU Awk is nonstandard, but it's definitely the most
intriguing option at this stage.
If anything, Unix users might be more receptive to ADB than
WinTel users, for at least two reasons.
First, they're already familiar with Awk, but even more
importantly: virtually all Unix programmers think in terms of
scripts and share the Unix ideal of building complex systems
with small, simple, flexible
pieces . . . whereas by contrast, typical
WinTel programmers have a greater tendency to favor
behomoth-sized
compiled executables.
Unix also makes a lot more sense for large volume
(I/O-intensive) processing, due to the substantially greater
underlying efficiency of the OS.
Return
to local table of contents
Return
to global table of contents
Frames mode, or
No frames
Next documentation section