[DUG] The BDE API formerly known as the Paradox Engine

[Paul Heinz]

Neven wrote: 

> You could probably say the same about ODBC ie trying to unify 
> the access method to an RDB and an ISAM have some fundamental 
> issues, and how many bites has M$ had at this ADO and RDO and 
> little lambs eat ivy....la la and they still couldn't do it 

Yes, ODBC is a horrible specification and a mirror image of the BDE in
some ways as it's relationally focussed and then got bent to fit
navigational sources - which means you need a SQL parser and execution
engine to get anything out of it. Hence we habe the ODBC driver kit
business where you can pay $10,000 US for a bunch of C .h files and
obfuscated .OBJs to map your navigational data onto. Mind you, maybe you
get the C source for your $10,000 US now... Oh joy!

But then, ODBC was designed by committee and boy does it show. It has 5
different ways of doing the same thing all with subtly different
implementation semantics and ambiguous documentation which is
effectively sometimes incorrect in that common apps don't follow the
rules either - not for want of trying probably. I know - we've written
an ODBC driver for our database engine in straight Delphi - no
unmaintainable and non-debuggable ODBC kit crap for us! Max did the
original heavy lifting from the ODBC spec but was so horribly scarred by
the process that he breaks out in hives whenever I mention issues with
it, so I get to diagnose and fix them ;-)

And indeed, there is all the RDO/ADO/something-DO variations that VB
spawned. 

Hoever, I think the underlying OLEDB architecture is actually pretty
clean and unambiguous compared to what came before them - somebody at
Microsoft learnt something from their previous attempts.

> well. I've had a number of stoushes on this list with people 
> who continue to spout that "I use [insert your favoured ISAM 
> here] is little projects but I use [Insert your favoured 
> RDBMS here] for larger ones"
> to which I'd say why bother with the ISAM (sometime not so 
> tactfully) because there are quite a lot of posts that also 
> start "I'm porting a project from [insert your favoured ISAM 
> here] to [Insert your favoured RDBMS here] and have a few issues....."

Yes, these days with the various 'free' (either as in beer or speech)
relational engines available, it's harder to justify not using one,
especially if you're starting from a clean slate and don't have any
legacy factors in play, like we do for example. 

But there still is the relational vs navigational difference which the
developer now needs to understand and surmount since the 3-letter
library acroynum du jour isn't doing it for you...

Without a good Nav-to-Rel mapper (which the most definitely BDE isn't
contrary to the brochure),
if you want to start Nav for whatever reason, that might be be a valid
engineering tradeoff but transitioning away from that to Rel model is
going to cost you. Sad but true.

TTFN,
  Paul.