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

[Neven MacEwan]

Paul

I sometimes wonder if the problem is that developers start with too 
small sets of
test data and design their navigation  logic around that not realising 
of course in real life
above a 100 records or so the rules change

One thing I hated about ADO was its insistence on concurrency control, I 
design my dbs
so concurrency is not required but it insisted on it, which was also a 
legacy of 'client side'
business logic (ie VB/Access apps), it was I must say a step up from the 
BDE
'Primary Key? what's a Primary Key?' approach

Maybe we should start a list -- 10 no a 100 things i hated about the BDE

N

> 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.
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject: unsubscribe
>
>
>