Re: OO4O 2.1 vs MDAC
- From: Ragzy <Ragzy@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 20 May 2008 20:50:02 -0700
Thanks Ralph,
That really gave me some idea now.
Actually I want to justify some of the facts that OO4O 2.1 (16-but) isn't
having when compared to MDAC/ADO.
Please note, The present app is on VB 3 using Oracle 7 Client tools, however
the newer version should go on VB6 / VB.NET.
I have noticed some of the Oracle disconnection problems and SQL16W95.DLL
GPF errors in existing application. I also wonder that performance would be
hit if we add up more functional changes / more Oracle calls (DMLs).
Any ideas on the above? Kindly let me know.
Regs,
"Ralph" wrote:
Like all technologies, in spite of a what proponents might say about any.
particular technology, there often isn't as clear a difference as we would
hope. And when there is - it is often depended on a specific context.
Tougher to do what you ask that you might think. <g>
Also appreciate that with ADO you still have to select a provider/driver
(OLE DB or ODBC) in general you will want to use the "Oracle OLE DB
Provider", or if you have the budget - a directData provider. (I'll still
make a few comments on ODBC below, for symetery.)
Also you don't mention the Oracle version there are differences between
pre-7, 7, and 9i. Things change.
Here's my over-view in no particular order.
ADO
Asynchronous
Runs in separate process space
Extra layer above the Oracle CLI
Updates can done reliably only with the Command Object
Works with MTS/COM++ (OO4O doesn't)
*does not bind SP parameters
ADO/OLE DB
Runs with less layers (ie, not ODBC)
But there is one possible problem (supposeably fixed with latest 'n
greates) -
has trouble with server-side cursors. Can occasionally just quit. May be
fixed.
ADO/ODBC
A little more stable than OLE DB for older Oracle versions
Oracle ODBC driver is quicker than MS
But always has extra layers as ADO always requries OLE DB plus the ODBC
plus the CLI
The real point with the above - is don't just select one provider and think
that it is IT. The provider will be a very active player and results will
depend on what you are doing. You will be testing several.
OO4O
Synchronous
Runs in process only (as a dll)
Direct through CLI - less layers
Binds Oracle variables
Update through dynasets - easiest to code
Built for Oracle SP - understands ref cursors, etc.
(ie, you be doing some code changes for ADO which will not be a
direct replacement - behavior MAY change all updates will have to be tested
etc.)
Multi-threaded (free and apartment)
Requires a COM wrapper to work with COM++ (MTS, ActiveX Exe, ASP, etc.)
Has to be used with Early-Binding or it is SL0000000WW!
(I mean, it displays even worse than normal Late-Binding issues. It is
an IDispatch Nightmare! <g>)
Well, that's my list. hth
PS: What "The transaction isolation levels in ADO 2.8 and OO4O 2.1"????
I think the above answers that question, if not repost more info.
-ralph
- Follow-Ups:
- Re: OO4O 2.1 vs MDAC
- From: Ralph
- Re: OO4O 2.1 vs MDAC
- References:
- OO4O 2.1 vs MDAC
- From: Ragzy
- Re: OO4O 2.1 vs MDAC
- From: Ralph
- OO4O 2.1 vs MDAC
- Prev by Date: Re: OO4O 2.1 vs MDAC
- Next by Date: Re: How to lock an MSSQL server recordset for read?
- Previous by thread: Re: OO4O 2.1 vs MDAC
- Next by thread: Re: OO4O 2.1 vs MDAC
- Index(es):
Relevant Pages
|
