Can anyone tell me advantages / disadvantages of DataDirect Server
Wire ODBC-driver?
Any experiences?
What about redistribution?
Andreas Lauffer, easySoft. GmbH, Germany 4 5557
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
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
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
"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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Andreas Lauffer |
last post by:
Can anyone tell me advantages / disadvantages of DataDirect Server
Wire ODBC-driver?
Any experiences?
What about redistribution?
Andreas Lauffer, easySoft. GmbH, Germany
|
by: Stylus Studio |
last post by:
DataDirect XQuery(TM) is the First Embeddable Component for XQuery That
is Modeled after the XQuery API for Java(TM) (XQJ)
BEDFORD, Mass.--Sept. 20, 2005--DataDirect Technologies...
|
by: diskoduro |
last post by:
Hi!!
Years ago I built a database to control the production of a little
factory.
The users wanted to work in a Windows Net workgroup so I created an
mdb with all the tables and data an after...
|
by: John |
last post by:
Hi
We have a front end/back end type access app. We would like to upsize the
app to sql server but can not re-write the whole app immediately. Is it
feasible to just upsize the backend (data...
|
by: TC |
last post by:
I have an Access database application with a lot of custom row
functions written in VBA. In other words, a lot of queries contain
calculated fields which use functions defined in the modules.
I...
|
by: Maricel Espejo |
last post by:
Hi,
Is there anyone encountered this error before & how it is being resolved?
Missing end comment mark '*/'
The error pops-up when I was running a DTS Import/Export from a SQL server...
|
by: tlyczko |
last post by:
Hello,
We have Access databases (backends) that will eventually be
consolidated into a SQL Server database, to facilitate data reporting,
analysis, etc.
Some queries in one Access database...
|
by: Stylus Studio |
last post by:
Dear comp.text.xml,
DataDirect XML Converters 3.1, Java and .NET components that provide
bi-directional, programmatic access to non-XML files including EDI,
flat files and other legacy formats,...
|
by: Stylus Studio |
last post by:
Dear comp.databases.ms-sqlserver,
DataDirect XML Converters are Microsoft .NET and components that
provide bi-directional, programmatic access to non-XML files including
EDI, flat files and...
|
by: Rina0 |
last post by:
Cybersecurity engineering is a specialized field that focuses on the design, development, and implementation of systems, processes, and technologies that protect against cyber threats and...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: erikbower65 |
last post by:
Here's a concise step-by-step guide for manually installing IntelliJ IDEA:
1. Download: Visit the official JetBrains website and download the IntelliJ IDEA Community or Ultimate edition based on...
|
by: kcodez |
last post by:
As a H5 game development enthusiast, I recently wrote a very interesting little game - Toy Claw ((http://claw.kjeek.com/))。Here I will summarize and share the development experience here, and hope it...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: DJRhino |
last post by:
Private Sub CboDrawingID_BeforeUpdate(Cancel As Integer)
If = 310029923 Or 310030138 Or 310030152 Or 310030346 Or 310030348 Or _
310030356 Or 310030359 Or 310030362 Or...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: lllomh |
last post by:
How does React native implement an English player?
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
| |