| Subject | Re: [firebird-support] BDE Question |
|---|---|
| Author | Helen Borrie |
| Post date | 2006-05-02T07:12:38Z |
At 11:48 AM 2/05/2006, you wrote:
that don't natively support SQL - such as Paradox - and even then
humans don't see it.
The BDE is great for Paradox - which should come as no surprise,
since it *is* Paradox.
write client code that will work with anything - you're apparently
not concerned with efficiency, elegance or access to all of the
features of Firebird.
If there was a BDE driver that fully supported Firebird (which
there's not, and never will be) you could consider it for a single
user, stand-alone system - not as the best choice, but perhaps
justified as "to know it is to love it". But, on networks, the BDE
is made for file-served databases on very small LANs, not
client/server databases. It simply doesn't support the transactional
model for multi-user concurrency. What is does in Firebird's case is
to remove transactions from the picture entirely and create Paradox
tables to store the output of queries. When attacked in this manner,
Firebird *will* enforce transaction atomicity. For the BDE's part,
it controls the right to create and destroy its intermediate tables
using file-level locks. That's more than enough to make the model
both vulnerable and unstable. But, moreover, it allows log-jams to
occur in the housekeeping of the database that will become
intolerable to users before long.
At Delphi 6, about 6 years ago now, Borland gave away the BDE as an
interface for anything but file-served database systems. They
shipped the last-ever version of the BDE (5.2) with an InterBase
driver that partly works with IB 6 and even-more-partly works with
Firebird. They replaced the BDE for real database engines with
DataBaseXpress. From the POV of supporting the features of the
engines it's no advance: it still "dumbs out" the transactional
aspects; but at least it's possible to customise it to a friendly
level, it's very light in weight and it's closer to the API. At
www.upscene.com you can find (and trial) an inexpensive commercial
DBX driver for Firebird that's said to work well for those situations
where you want to stay close to the generic and don't care about
what's happening under the surface.
If you want to consider getting serious about your applications'
connectivity with Firebird, as Adam suggests, you have a couple of
good options and quite a few others to choose from. And I suppose
you already know that your TTable days are over...all off-topic in
this list, however.
./heLen
>Hi,OK, I'll try to be concise...
>
>Can someone point me to some documentation explaining concisely the concerns
>some people have with using the BDE to access a firebird database.
>The reason I ask is that I have been experimenting and have been looking atStrange. The BDE isn't designed to generate SQL - except in drivers
>the logs created by BDE as it does its thing. What concerns me is that when
>searching for information about firebird I
>have found that peoples general attitude to the BDE is very negative, yet
>when I examine the logs I am finding that the BDE is doing a great job - the
>SQL generated is excellent.
that don't natively support SQL - such as Paradox - and even then
humans don't see it.
The BDE is great for Paradox - which should come as no surprise,
since it *is* Paradox.
>Given that I must support different databases (including Paradox) IWell, *given* that requirement - by which one assumes you want to
>wonder what all the fuss is about.
write client code that will work with anything - you're apparently
not concerned with efficiency, elegance or access to all of the
features of Firebird.
If there was a BDE driver that fully supported Firebird (which
there's not, and never will be) you could consider it for a single
user, stand-alone system - not as the best choice, but perhaps
justified as "to know it is to love it". But, on networks, the BDE
is made for file-served databases on very small LANs, not
client/server databases. It simply doesn't support the transactional
model for multi-user concurrency. What is does in Firebird's case is
to remove transactions from the picture entirely and create Paradox
tables to store the output of queries. When attacked in this manner,
Firebird *will* enforce transaction atomicity. For the BDE's part,
it controls the right to create and destroy its intermediate tables
using file-level locks. That's more than enough to make the model
both vulnerable and unstable. But, moreover, it allows log-jams to
occur in the housekeeping of the database that will become
intolerable to users before long.
At Delphi 6, about 6 years ago now, Borland gave away the BDE as an
interface for anything but file-served database systems. They
shipped the last-ever version of the BDE (5.2) with an InterBase
driver that partly works with IB 6 and even-more-partly works with
Firebird. They replaced the BDE for real database engines with
DataBaseXpress. From the POV of supporting the features of the
engines it's no advance: it still "dumbs out" the transactional
aspects; but at least it's possible to customise it to a friendly
level, it's very light in weight and it's closer to the API. At
www.upscene.com you can find (and trial) an inexpensive commercial
DBX driver for Firebird that's said to work well for those situations
where you want to stay close to the generic and don't care about
what's happening under the surface.
If you want to consider getting serious about your applications'
connectivity with Firebird, as Adam suggests, you have a couple of
good options and quite a few others to choose from. And I suppose
you already know that your TTable days are over...all off-topic in
this list, however.
./heLen