DataDirect Server Wire vs. MS ODBC

[Andreas Lauffer]

Can anyone tell me advantages / disadvantages of DataDirect Server
Wire ODBC-driver?
Any experiences?
What about redistribution?

Andreas Lauffer, easySoft. GmbH, Germany

[Albert D. Kallal]

Well, first, I have never heard of the product. However, I did do a quick
google search, and did take a quick walk through their web site.

However, if you are talking about ms-access and using the mdb file format,
then ODBC does NOT apply. (and nor does that product).

Further, ms-access when used with the JET database engine is NOT a client to
server setup (it is a file share, and again ODBC does not apply). That being
the case, then the DataDirect Server odbc driver would NOT apply to
ms-access when used with JET to a mdb file share. (so, in effect, your post
is way off topic for this group).

However, most certainly that datdirect driver would apply when using
ms-access and JET and then connecting to a server based system like Oracle,
or sql-server. (ms-access can be used as a client to those data base
systems).
The whole pretext and arguments given to use the ODBC datadirect drivers is
that they are more efficient then using the native connection to the data
base (that is a ADO connection, and the OLE provider in place of ODBC).

However, most of the time, most developers will tell you that using ODBC vs
OLEdb is not that much different anyway. It is really is kind of a fake
story, or assumption that much of the marketing hype out there tells use (it
says that using OLEdb over ODBC is far more efficient...and that is pure
bunk. Only fools buy into that. So, basically these folks are assuming that
everyone is dumb, and assumes that OLEdb is far superior to ODBC. However,
OLEdb is preferred over ODBC, and can often be fare more feature rich
(things like data cubes etc). So, their is certainly some performance
advantages of OLEdb over ODBC, however *most* of the time, the advantage is
NOT realized.

The main benefit I can see of that DataDirect Server is that the ODBC
drivers have compression built in at each end. This no doubt could certainly
improve the data transfer rate as most sql server data is text, and it
compresses very well indeed. So, basically they are selling a ODBC driver
with compression for some major server based engines.
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
ka****@msn.com
http://www.attcanada.net/~kallal.msn

[Bob Beauchemin]

Couple of points...

Wire protocol means the native protocol used by the database. This would be
TDS in the case of Sybase or SQL Server, TNS (or a level lower) in the case
of Oracle. It does not mean "that is a ADO connection, and the OLE provider
in place of ODBC" at all.

Using wire protocol means that you do not need database-specific client
software on every machine. As an example, Microsoft ODBC for Oracle and
Oracle ODBC require that an Oracle client be installed, as they use OCI to
communicate with the database. DataDirect wire protocol driver does not.

OLE DB, ODBC, ADO, RDO, etc, are generic layers over database access.
Depending on how you write the driver/provider this may or may not require
database-specific client software. ADO is a layer on top of OLE DB, RDO is a
layer on top of ODBC.

it says that using OLEdb over ODBC is far more efficient
I've never heard this anywhere. Where did you read this?
DataDirect Server is that the ODBC
drivers have compression built in at each end
Where did you read this? Wire protocol != compression. If there were
compression it would be orthogonal to wire protocol.

Cheers,
Bob Beauchemin
http://staff.develop.com/bobb
"Albert D. Kallal" <ka****@msn.com> wrote in message
news:SX***********************@news3.calgary.shaw. ca... Well, first, I have never heard of the product. However, I did do a quick
google search, and did take a quick walk through their web site.

However, if you are talking about ms-access and using the mdb file format,
then ODBC does NOT apply. (and nor does that product).

Further, ms-access when used with the JET database engine is NOT a client to server setup (it is a file share, and again ODBC does not apply). That being the case, then the DataDirect Server odbc driver would NOT apply to
ms-access when used with JET to a mdb file share. (so, in effect, your post is way off topic for this group).

However, most certainly that datdirect driver would apply when using
ms-access and JET and then connecting to a server based system like Oracle, or sql-server. (ms-access can be used as a client to those data base
systems).
The whole pretext and arguments given to use the ODBC datadirect drivers is that they are more efficient then using the native connection to the data
base (that is a ADO connection, and the OLE provider in place of ODBC).

However, most of the time, most developers will tell you that using ODBC vs OLEdb is not that much different anyway. It is really is kind of a fake
story, or assumption that much of the marketing hype out there tells use (it says that using OLEdb over ODBC is far more efficient...and that is pure
bunk. Only fools buy into that. So, basically these folks are assuming that everyone is dumb, and assumes that OLEdb is far superior to ODBC. However,
OLEdb is preferred over ODBC, and can often be fare more feature rich
(things like data cubes etc). So, their is certainly some performance
advantages of OLEdb over ODBC, however *most* of the time, the advantage is NOT realized.

The main benefit I can see of that DataDirect Server is that the ODBC
drivers have compression built in at each end. This no doubt could certainly improve the data transfer rate as most sql server data is text, and it
compresses very well indeed. So, basically they are selling a ODBC driver
with compression for some major server based engines.
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
ka****@msn.com
http://www.attcanada.net/~kallal.msn

[Bob Beauchemin]

I've read the links that you pointed to and they say nothing about OLE DB.
They're comparing an ODBC driver that uses wire protocol and *OCI* (Oracle
call interface) programming.

ODBC and OLE DB are just specifications of a series of functions (ODBC) or
interfaces and cotypes (OLE DB) that you as a programmer use in a (in
theory) data source-independent manner to get access to data. Oracle and
Microsoft ODBC drivers use OCI to implement these functions. OCI is an
Oracle-specific series of functions that eventually use the wire protocol
(series of bytes that goes out over the wire to talk to the database) to
talk to Oracle. DataDirect implements their ODBC driver to directly use the
wire protocol to implement the same functions, thus cutting out one layer of
indirection. They also don't need an OCI layer (oci.dll and friends) which
enables them to work *without installing Oracle client software* on each
machine. The compression part is also interesting (and I hadn't heard of it
before, thanks for pointing this out), but is not necessarily the main
benefit. Leaving out the extra layer of OCI calls could also make it run
faster. So:

programmer -> ODBC -> OCI -> wire protocol -> Oracle DBMS : (Microsoft and
Oracle implementation)
programmer -> ODBC -> wire protocol -> Oracle DBMS : (DataDirect
implementation)

article claims:

programmer -> Data Direct ODBC -> wire protocol -> Oracle DBMS (requires no
Oracle client) faster than
programmer -> OCI -> wire protocol -> Oracle DBMS (requires Oracle client,
OCI)

Bringing OLE DB into it obfuscated things for me. I've never heard anyone
claim that "using OLEdb over ODBC is far more efficient" than wire protocol,
native ODBC, or OCI. As OLE DB over ODBC is a level of programming calls
over native ODBC, however its implemented. Native OLE DB *could* be faster
than native ODBC but not necessarily. It depends more on how the
drivers/providers are implemented than which spec you use.

Hope this helps,
Cheers,
Bob Beauchemin
http://staff.develop.com/bobb
"Albert D. Kallal" <ka****@msn.com> wrote in message
news:NQ************************@news3.calgary.shaw .ca...

"Bob Beauchemin" <no**********@comcast.net> wrote in message
news:1i*******************@rwcrnsc51.ops.asp.att.n et...

Couple of points...

it says that using OLEdb over ODBC is far more efficient
I've never heard this anywhere. Where did you read this?

From their web site:
http://www.datadirect-technologies.c...rth-report.asp

ODBC has been widely adopted as the standard API for coding database access because it makes SQL applications portable across databases. Yet, some in
the information technology community have held off on adopting ODBC due to a commonly held misperception that the benefits of ODBC came with a
performance penalty, i.e., that application performance with ODBC was slower than using a proprietary (native) API such as Oracle's OCI (Oracle Call
Interface.)

Now, with a new independent study from database expert Ken North, the results prove that in most situations, applications written with

DataDirect Technologies' wire protocol ODBC drivers actually outperform native
programming by a wide margin.

So without question, the company at this mentioned web site certainly agrees with me that this is misperception. (and I certainly think it is also).

Again, what is meant by native programming on the client side? So, while the developers might not see, or use the native API when using a ADO OLE db
provider, the OLEprovdier most certainly does use the database native api!. I thought that was the whole idea of OLEdb! In fact this is the WHOLE BASIS as to why claims are made that OLEdb is a big jump over ODBC. So, no, ADO
don't give you native api access, but the OLEdb provider most certainly
*USES* the api. If a OLEdb provider does not *use* the native API's to the
server, then just what heck does it do? Or rather what does it use to get
access to the database? I mean, why then even bother to drop ODBC and use
OLEdb?.

Regardless, the above does clearly state:

Yet, some in the information technology community have held off on

adopting ODBC due to a commonly held misperception that the benefits of ODBC came
with a performance penalty

And, I certainly agree that it is a commonly held misperception also.

This misperception is again noted on this following page:

http://www.datadirect-technologies.c...-commentary.as p
many developers and architects don't use ODBC, primarily because they

perceive that its benefits come at the expense of application performance.
The ODBC performance penalty is a myth that was dispelled a long time ago,
yet people continue to believe it.

DataDirect Server is that the ODBC
drivers have compression built in at each end

Where did you read this?

Right here:

http://www.datadirect-technologies.c...-commentary.as p

Because our wire protocol technology is built from the ground up with a streamlined design that is optimized for network performance. For example,
our Oracle driver uses compressed data packets that are allowed by the

wire protocol that our drivers use, but not by the wire protocol that Oracle Call Interface (OCI)

Wire protocol != compression. If there were
compression it would be orthogonal to wire protocol.
No, not saying that write protocol= compression, but I am certainly saying
that their drivers DO IN FACT USE compression, and it is a great benefit.

In fact, I would bet that the compression is going to responsible for more of
increase in performance then just straight ODBC connections! Since ODBC
performs generally as well as the OLEdb provider anyway (which uses the
native API), then the only real reason why performance is gained here is due mostly to the compression issue, and NOT the OLEdb native api vs ODBC.
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
ka****@msn.com
http://www.attcanada.net/~kallal.msn

[Albert D. Kallal]

"Bob Beauchemin" <no**********@comcast.net> wrote in message
news:OJEbb.406612$cF.123861@rwcrnsc53...

I've read the links that you pointed to and they say nothing about OLE DB.
They're comparing an ODBC driver that uses wire protocol and *OCI* (Oracle
call interface) programming.
You are correct. However, the quotes concerning ODBC were MOST certainly of
a
"general" nature, and were speaking of the "general" misconceptions in the
industry of using ODBC. Those "general" misconceptions were not in reference
to wire protocols. In fact, those misconceptions no doubt in part due to the
fact the 99% of the time when ODBC is dropped, a OLEdb providers is used! It
is
reasonable to assume that a statement of "general" misconceptions applies to
99%
of the cases out there.

Bringing OLE DB into it obfuscated things for me. I've never heard anyone
claim that "using OLEdb over ODBC is far more efficient" than wire protocol,

No, no one is saying that OLEdb over ODBC is more efficient then wire
protocols. However, without question, the GENERAL wide spread misconception
in our industry is that OLEdb is MORE EFFICIENT then ODBC! This is exactly
what the general misconception they are speaking of. Since so few use wire
line protocol, it can't possibly be a general misconception yet at all. If
you
came to me and said we have some special new ODBC drivers that can use wire
line protocol, and further USE COMPRESSION, do you really think anyone would
argue that
this will not work well? I don't think anyone would be surprised one bit. I
mean, sure most would agree that ODBC is slower then some wire protocol, but
as a "general" rule I can't remember ever seeing ODBC replaced in this
context.

It is certainly possible that the ONLY reference to the "general"
misconceptions is that the company DOES have a ODBC driver that works as
well as wire protocol, that certainly would be grounds for surprise to a lot
of people. I don't think I would call that "general" misconception in our
industry...but that may very well be the context that the web site is
referring to.

Native OLE DB *could* be faster
than native ODBC but not necessarily. It depends more on how the
drivers/providers are implemented than which spec you use.

Yes, I totally agree with the above. However, the industry as a whole has a
general misconception is that the native providers are FAR better then
ODBC.

As mentioned, it is certainly possible that I am taking those "general"
statements out of context from that web site. I do not believe that I am
doing so, and it most certainly is not my intention to do so!

I also still think that much of the speed increase is still due to the
compression, and I would love to see the same benchmark with the compression
turned off.

At the very least, I do thank you for clearing some points. I did assume
that most of the comments were referring to OLEdb, and that may not be the
best context here. When I think of native access to a database, I tend to
think right away of the OLEdb provider. Most of the time we use the OLEdb
providers via ADO, but that don't have to be the case (I should have NEVER
mentioned ADO..but only spoke in terms of OLEdb).
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
ka****@msn.com
http://www.attcanada.net/~kallal.msn