Re: OO4O 2.1 vs MDAC

"Ragzy" <Ragzy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
Hi There,
I have a typical scenario here. We're planning to move VB3 using OO4O 2.1
16-bit to VB6 with MDAC 2.8 / ADO or VB.NET with ADO.NET.

Now I must distinguish and list out some of the features that ADO /
has over OO4O to induce the client to fund for this migration.

I'd tried to find any such differences apart from their architecture /
functionalities, but no luck.

Can you all list out some of the differences between these 2 technologies
i.e., ADO and OO4O 2.1 especially that is performance related will be an

for eg:
The transaction isolation levels in ADO 2.8 and OO4O 2.1

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.
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
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
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.

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
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.