Hi Everyone,
I hate to weigh in on this conversation, but as most of you know, I am
rarely without an opinion; and after writing this and returning to this
sentence I can say a long winded opinion.
To start with let me say I love DataPerfect.
But for many things the ship sailed for me back in the late 1990's with
server type databases such as MS SQL Server, MySQL being so pervasive in the
marketplace; and Access as both a front end client, of backend file
database, or both. My reasons were purely pragmatic, Access was bundled with
versions of Microsoft Office so many business had it as standard on their
PC's and it tempted people, who had no or little understanding of relational
databases, to write business applications which ultimately became unwieldy
and they then needed a specialist to come in and fix, or rewrite their
applications. I got a lot of work this way. Access also offered and easy
pathway to the backend servers.
I also dabbled over the years with other databases, FileMaker, Paradox,
Alpha, LibreOffice and OpenOffice from which LibreBase was derived. The
majority of these had variants of SQL (Structured Query Language) as the
data manipulation language. Depending on the variant SQL can be quite a
powerful manipulation language, albeit not at all trivial to learn. I like
SQL, but other than the very simple it is quite hard to use and very
abstract for most people.
Before DataPerfect I mainly used DB3, DB4 and Clipper, (also a bit of
Paradox), or even direct file i/o. None of these were based on SQL or
anything particularly like it, so you really had to work hard to manage
data. You most you had to load and open individual tables (files), an
indexes which also were in files and then search for data in the index and
point back to the table. In most cases each index was a separate file, so
when you opened a table, if you needed to update any data, you had to make
sure you opened all the indexes related to the table, otherwise the indexes
would get out of sync. It was quite common to run daily or weekly reindexes
to make sure everything was ok. Multi-user work was incredibly difficult,
because generally if someone opened a file to create or update, then you
needed to lock others from using the file, if they happened to have a record
open, you had to write lots of programming code to work out how it all
fitted together.
At one time in that DOS era when I had a dry patch, with little work, I
spent the time writing a shareware program, called Rendezvous, which was to
be a low end telemarketing, and direct mail program.
At that time WordPerfect was reigning supreme in the word-processing field,
and after playing a little with it, I realised that with the help of the
public available SDK (software developer kit) I could create synthetic
Secondary data files which could be used by WordPerfect for merging with
Primary (template) files for creating letters and even reports. Prior to
using WordPerfect I had to create all the output from my DOS program,
WordPerfect was a God-send in that it had printer drivers. I didn't make
much money in the shareware market, but I gave away many copies of
Rendezvous, and I managed to get a lot of work supporting WordPerfect. As I
updated Rendezvous, I included the ability to import WordPerfect secondary
files. It always amazed me how many businesses kept client records as
WordPerfect Secondary format files, but as they say, if the only tool you
have is a hammer, everything is a nail. I sold many copies of WordPerfect
as clients found the benefit of databases rather than word processors for
storage and management of data, I was happily in the WordPerfect family.
Following Novell's footsteps, but preceding Microsoft, WordPerfect brought
out a certification program for consultants. So I did the exam and became
one of a handful of WordPerfect Certified Resources in Australia.
(Digressing slightly, the handful of Certified Resources, formed a group,
the Association of WordPerfect Professionals, which we, quite unbelievably,
still have regular meetings, despite the WP ship having sailed for everyone
ages ago). WordPerfect back then had a few DP customers, but they didn't
have a lot of support for it, so they gave me a free copy and sent me leads.
I had a client who wanted a custom payroll system. They had looked at off
the shelf systems but they did not suit them. I had a meeting with the
client, and was planning to write their application in Clipper, but their
requirements were vague so I decided to prototype it in DP. The prototype
was basic, I didn't know DP well but it was quick to knock up the prototype.
The client kept changing things, so I kept it at the prototype stage. The
further it went the more I worried about how to convert it from the
prototype to Clipper. During one meeting with the client I had it on the
network, and unbeknown to me, my client opened another instant on a
different workstation. I did something and then a short message popped up
letting me know that another client had edited a record. The thing is, my
edit still stood, and my client's record also still stood - no one got
locked out and our data did not get trached. At the time this was almost
unheard of in a database, especially a "toy" one like DP. After tidying the
prototype up, it became the final program, and I was amazed, and my client
was delighted. That kicked off a long association with DP and I still have
some web applications ticking along today.
Back to the multi-user, even today, doing this apparent field level locking
trick is not an easy thing. It wasn't until the developers conference in
Huntington Beach in 2004, where Lew explained how DP handled concurrent
record edits that I understood why it worked. It was in this discussion I
realised how different DP was to other databases. File, page and record
locking in other database products are terribly processor intensive, but
DP's relativistic "locking" or non-locking is where DP gets some of its
phenomenal performance
The thing that made DP so quick in the design phase was that the form
("panel") was not just a representation of the data added on after the data
was established, but instead was the definition of the data, the display of
the data; plus the behaviours of the data. In other database products (with
perhaps a couple of exceptions, I think one is FileMaker), you create a
table as a totally separate exercise, with very definite thinking about the
meaning and structure of the data and how it fits with other data. You
generally layout an entire set of tables, and indexes, and relations,
queues, (and in some more advanced databases some behaviours - triggers,
stored procedures etc). Whereas in DP, things like keeping a total, or
automatic creation of related records etc, are bound up in the panel
specification. Panel links and data link offer a far more sophisticated
ability to relate tables in multiple ways. Just take the recursive panel
link for automatic numbering, it's power and simplicity takes a lot of skill
to do in other products. To have multiple panel or data links to another
table (panel), or either, makes the relationship between data far more
dynamic and controllable than in say the CONSTRAINTS mechanism of SQL
databases. So with DP you can just open up a panel, and visually design a
structure, and one frequent curse of DP is that you can only create as many
fields as will fit on a screen, actually turns out to be a good way to
create structure, let a novice out with Microsoft Access, OpenOffice, Alpha,
LibreOffice and you get loads of columns, and they "encourage" the novice to
break all the rules of normalisation and good data design. But DP forces
logical structure in a very non-intrusive way. Sure you can get DP all
wrong, but if you were going to get it wrong in DP, you would be likely to
get it horribly and probably fatally wrong in products like LibreOffice.
Back to the hammer and nail analogy, most people find relational (3D) data
difficult, and they design SQL databases in the way they design it like 2D
data similar to spreadsheets, so often even with relatively experienced
programmers, you often get the sense that everything is a spreadsheet - and
yes, you can do some minor relational work with a spreadsheet if you know
what you are doing, but not a lot.
Ok, so I am a programmer and DP does not have a programming language. Yes,
to me it is a problem, it is DPs only serious weakness for me, I am
constrained to doing things the DP way, but DP does so many good things that
would take so many hours, days, weeks to do with other products, that it is
not such a bad price. DP does however have a powerful "programming"
language, which in 2004 became exposed to the world. No, not the horribly
bad Shell macro system (sorry to offend its users), but the Report language.
Many front end database clients have a built in report writer, but DP goes
far beyond this with the ability to totally manage data from within a
report. When you work with DP for the web, using the facilities that Lew
(and others) added immediately after the Huntington Beach developers
conference in 2004 , so that you can use synthetic data-logs, and "automate"
the execution of reports outside of DP. This meant that DP could be taken to
a totally new level exposed to the world. Conceptually it changes the way DP
is used. You still get to design DP in the same panel based way, adding the
behaviours etc, but then you can program the database CRUD (create, read,
update, delete) interactions totally through reports. This means that you
can use a variety of other clients, to pass data to and from DP. You can use
DP as a powerful database (far more powerful that any file based database)
from VB, VB.Net, C, or generally whatever programming language you prefer -
including running scripting from a web site. This means that DP can be
utilised more like a powerful backend server database, without the
difficulty of use, the cost and complexity of a backend server, plus hardly
any restrictions in what you can do in the client. I emails, send SMSes,
display graphs, maps, with DP as a backend.
In an nutshell, you can go looking for lots of other database products, but
I do not think you will find any delivering the goods like DP does.
That's my 2 (thousand) cents worth.
Regards
Brian
