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