Hiya All
Firstly ADO vs BDE, I've been using ADOExpress with MSSQL7 and I assume the ADO
components use a cursor to access the
database, Cursors are probably the most elegant way to access/update Data on SQL
server from an interactive front end since they are bidirectionally scrollable and
updatable i.e. they closely match the behaviour of data controls such as a grid. One
could consider a cursor as a 'virtual ISAM' access to an SQL server. And this is the
reason that I like ADO because despite the obvious advantages of SQL servers SQL was
never designed to operate in an interactive mode - it was a batch update system. With
cursors you get all the advantages of SQL (such as index independance and select where
clauses and triggers, et al) and the interactive behaviour of ISAMS.
The BDE on the other hand was designed to present a consistent level between
applications and database (both ISAM and SQL). In the case of an SQL Database and a
TQuery component it does this by deriving an UPDATE statement from the SQL SELECT
STATEMENT. The BDE then caches it's SELECTED fields and executes the derived UPDATE
statements as required. This has several problems the least of all that you cannot
refresh a TQuery and the rather tortuous (and therefore slow) UPDATE statements it
submits. Also in the case of Surrogate keys the TQuery gets 'lost' as it cannot
support the concept of the server altering data since it assumes the primary key is
the whole row (upWhereAll).
Most of the bulk of the BDE is redundant when accessing an SQL server since most of it
seems to be adding SQL functionailty to the ISAM databases (DBASE, Paradox) it
supports including Cached Updates which seem redundant on an SQL server which
implements it's own transaction control.
In brief ADO makes SQL servers into virtual ISAM, BDE makes ISAMS into virtual SQL
I cannot understand the recent diatribe over Intebase generators and MS SQL Identity
columns (they are basically the same thing)
Indentity columns are declared at the table level and have the same seed and increment
parameters. Generators are independantly declared and update the target table in the
trigger (pls correct me if im wrong). I think the problems you may be having are more
to do with the BDE than the identity column. I don't use surrogate keys (to me they
are an anachronism, simply some sort of storage/index optimisation that is now
redundant). I prefer descriptive AlphaNumeric Primary Keys. As it make more sense for
a customer to be 'MWK001' than 132. And with trigger enforced RI (declaritive is to
restrictive) anything is possible
Hope this fires you all up
Neven
application/ms-tnef
