Hello,
    Can anyone recommend a Delphi toolkit which allows you to easily work
with the MS SQL Server client thereby, by passing the BDE. I have used a
similar product for Oracle called Direct Oracle Access (DOA) which bypasses
the BDE and works directly with the Oracle client DLL(oci.dll) and found it
to be a very robust toolkit. Can anyone recommend or have knowledge of a
similar Delphi toolkit for MS SQL Server.
    thanks!

"Douglas Kurtz" <nos...@work.com> wrote

Douglas,
ODBC, OLE DB, and ADO are the ones you need to interface with MS SQL Server.
ADO functionality is available in Delphi 5.

-- Reddy Palle.

    I need something faster than ADO or ODBC drivers. And I don't have time
to write OLE DB driver. Thanks for input.

faster for what? Select, update, insert, delete? Firehose cursors are pretty
fast, and the IRowsetFastLoad interface is pretty quick at inserts.

I have used ODBC express,  which has given me great performance.  And it
works well with Oracle and MS SQL.  However, you can look at kyles page
which list many BDE alternatives http://www.kylecordes.com/bag/index.html.

Edwin

news:92garv$23i3@bornews.inprise.com...

In addition to what Justin said, native ODBC (dunno about BDE based ODBC)for
SQL Server in MDAC 2.1 is faster than OLE DB or ADO. In MDAC 2.6 ODBC is as
fast as OLE DB and faster than ADO.

You would not need to write an OLE DB Provider to use OLE DB you would need
to write an OLE DB consumer.

-Euan

news:92gdf7$23h5@bornews.inprise.com...

    Faster selects and updates. ADO is too slow and working with ODBC must
go through BDE which must execute on one thread. This application is a time
critical application in which I need to execute multiple threads which can
work concurrently on separate processors. ADO is fine for web or other UI
development but not for time-critical applications.

The problem I have with ODBC is that unless I write my own code to work
directly with ODBC (which I don't have the time) the I must use the BDE. The
BDE will not execute on more than one processor in a multi-threaded
application. This application is designed to take advantage of large
multi-processor machines. By using the BDE all threads which interface with
the BDE must execute on the same processor. A complete waste of resources.

news:92gqe0$22v6@bornews.inprise.com...

HOW time critical? I (literally) perform tens of millions of inserts,
updates, deletes and selects every day with a multithreaded ADO app.

Justin,
    Time critical in the sense that every second of processing cost the
buisness big $. Have you compared speed of ADO vs BDE?
    If ADO can match performance of BDE I may be able to use ADO. ADO
however is another layer to go through so in the end a native solution
should always be faster.
    I'll try some performance test between ADO and BDE.
Thanks for input!

ADO absolutely killed the BDE for my stuff, even in single-threaded
scenarios. And it scales to SMP beautifully on my 4 way Xeon servers. And
MUCH more stable than the BDE for multi-threading. I have an app that
dynamically scales up to 20 threads, all using ADO connections and stored
procedures. Even at 20 threads, processor utilization is low - I'm waiting
on the SQL Server across the wire.

Justin,
    Sounds appealing. The place I am working have told me they ran some
benchmarks and ADO did not fair well against BDE. I'll try some my own
tests.
    Are there any ADO performance tuning issues I need to be aware of ?

I use a component called SqlQuery from http://component-store.com/.  It's
extremely fast and uses native SQL calls.  Try it out, I think you'll like
it.

--
Richard Stevens
rstev...@inreach.com

Richard,
    Is it stable?

If you are running on a multi proc box make sure you use MDAC 2.5 or above,
MDAC 2.1 does not scale above 2 procs.

-Euan

news:92iaom$p9i3@bornews.inprise.com...