Step 3: Choose the product to access that database
Having chosen the database file format or database server for your application,
you can browse the List By DB Server /
File Type to see which product could work. When comparing the
product, here are some features and topics to consider:
| File formats / database servers supported |
Obviously you need to choose a product that supports your chosen
file format or database server; moreover, you should choose a product
that is primarily targeted at the files/servers you are using.
Some of the products listed here support many, many formats, but specialize
in a few. If you want the best performance, usability, support,
use the product the way the vendor has in mind.
|
| Deployment |
The more computers the application must be deployed to, the more
important easy deployment is. This can vary widely between products:
Some compile completely in to your EXE; some requires DLLs.
The client/server solutions require drivers for the database server
they are access. Middleware-based solutions (ODBC, ADO, BDE)
will require that the appropriate middleware be installed.
For comparison's sake, the BDE require 2-3 megabytes of DLLs, etc.
|
| Data-aware controls |
If you are developing a GUI application, data-aware control support
is vital to rapid development. There are certainly situations
where data-aware controls are not appropriate, but it is wise to have
them available for those times when they are appropriate.
There are three levels of support:
- Proprietary: the product has its own data-aware controls.
This is better than nothing, but, in my opinion, not by much.
You will have to use only the vendor's controls, not the controls
that come with Delphi, or the hundreds of third-party controls
available. Proprietary controls also make it extremely difficult
to switch to different data access software later.
- Standard: most of the products support standard Delphi data-aware
controls, using one of two mechanisms explained below:
|
| BDE Replacement Mechanism |
In D1/D2, it was necessary to extensively reverse engineer the VCL/BDE
interface in order to use standard data-aware controls, because the
controls were tied to the VCL's BDE using classes where none of the
methods were "virtual", and therefore could not be replaced.
BDE emulation works, and permits a very BDE-like experience, but it
is definitely a kludge, albeit one that some vendors engineered very
well.
In Delphi 3, Borland "saw the light" and redesigned the
VCL to use a virtualized TDataSet, which makes it possible to create
components that can connect to standard data-aware controls as easily
as TTable and TQuery do. This method is far preferable
to the old BDE-emulation method, and nearly all vendors have switched
to it. The new method make installation of BDE alternative
much easier, redistribution of your product much easier, etc.
Further Delphi releases (4 and 5, so far) have refined the TDataSet
concept even more, so that BDE alternatives products based on TDataSets
work more smoothly than ever.
|
| Custom Controls:
|
If you use various custom controls (InfoPower, Orpheus, etc.), you
should verify that the product you are considering is compatible with
the products you are already using.
For a while, some third-party controls explicitly expect a BDE
TTable/TQuery, and simply did not work with any BDE alternative.
Some vendors (for example, Woll2Woll) are actively working with
BDE alternative vendors to produce special TDataSets that let allow
them to work with the controls (InfoPower).
At this point, nearly all custom controls work with a wide variety
of BDE alternative products.
|
| Report Printing: |
The same advice applies to report generation software (Ace, Report
Printer, QuickReports, Piparti, etc.)... make sure that you can use
your report software with the BDE alternative product you are considering.
|
| Full access to the feature set of the
database server? |
Some BDE alternatives will provide more access to the underlying
database's feature set than others. For example, database-server-specific
products like Interbase Objects and Direct Oracle Access can use the
underlying database APIs to make features available that cannot be
used via a middleware solution.
Most of the time, this distinction is not important; the middleware-based
software support everything that you actually need, and give the
advantage of greater database portability. However, if you
need a specific feature of a particular database server, you may
need to choose a "native" product to get it.
A major issue with with "native" products is that they
lock you in to the database they are native to; if you switch databases,
you will probably have to switch data access software, which usually
means a substantial rewrite of your application.
|
| Workarounds |
How trouble-free is it? Are workarounds needed for common
actions? Pay attention to support newsgroups and mailing lists
to learn this kind if information. (This information will be added
to the BDE Alternatives Guide over time, as well.)
|
| Support Policies / Bug Fixes |
What kind of support is available? If the vendor is located
in a different part of the world, calling may be very difficult; therefore
try to get a feel for how quickly and effectively they answer email
or support newsgroup queries. All software has bugs, but some
software gets fixed much more quickly than others.
|
| Query language support |
Many of the file-server-based solutions have no support for any
kind of query language; you may find that certain reports which could
be generated easily in an SQL-based environment will require significant
coding to gather the results "manually" in code. For developers
with significant SQL experience, this can be a big step backward.
|
|
|
kylecordes.com Headlines:
Rearranging files in SVN? Use git-svn instead. Need text? Hire a Writer Buy vs. Build Start with a Prototype On the Job Training Reading and Writing Playing to Win: Going Beyond the Call of Duty Please, Use a Web Application Framework Getting Started with Git and GitHub on Windows RocketModem Driver Source Package for Debian / Ubuntu
|
