Re: Intersolv's ODBC

alc_at_nyx (Alain Cheong Chun Lin) wrote:

>We are also currently evaluating an ODBC driver for a future project.Our
>current architecture includes Visual Basic as the tool for developing the
>applications and Oracle 7 as the database server. We are contemplating
>different approaches to access the database server.
>- Using ODBC from VB .(It is not recommended, VERY SLOW in performance)
>- Using the ODBC API directly, bypassing the JET entirely, (gives better
>performance than above).
>Both 2 options, using Intersolv's DataDirect ODBC driver for Oracle 7
>- Oracle Objects for OLE
>- Oracle Power Objects (which is still in Beta).
>We need to know if anyone used any of the above and have any opinions or
>comments to share with us.
>Right now, our preference is using the VB data control with API with Intersolv
>ODBC. The problem is we lack information on constructing the API fonctions.
>Anyone aware of any documentation/reference manuals on this subject ?
>Recently, on the net, I read a few very negative comments on Intersolv's
>ODBC driver for Sybase System 10. What about for Oracle 7 ?
 

>thanks,
>alain

Alain -

        I have spent quite a bit of time evaluating these same options for a commercial application that my company produces. Here are my findings:

        ODBC is a dog if you use the dynasets and stuff. You can use it SQLPASSTHRU mode which is quite fast - I could find no significant difference in speed between this method and using native OCI calls. However, figuring out how to use all the ODBC calls is a pain. We use Intersolv's Q+E Database Library to shield us from having to know all the ODBC stuff - it works great and is very fast. It also provides a bunch of features not easily doable with just ODBC such as local caching options. We have been forced to investigate alternate options, however, because none of the currently available ODBC drivers support return values from calling stored procedures or functions. Supposedly, Intersolv will have one available in a couple of months that supports this, but we can't wait and we're concerned that Intersolv might be the only ODBC driver that supports this. If return (output) from stored procedures isn't a problem then I would HIGHLY recommend ODBC through Q+E Lib.

        Oracle Objects for Ole is currently under investigation, but it doesn't look good. Here are the problems: 1) Documentation is non-existent. They provide an online help file and some sample code, but plan on spending loads of time trying to figure out how to make it work.
2) Our testing has shown performance to be slightly better than the "slow" ODBC method (not SQLPASSTHRU), but *FAR* slower than calling ODBC directly through Q+E. We tried all possible options including no local caching and setting the dynaset to read-only, but it's still slow as molasses.
3) It's got some quirky and annoying design problems. For example, bound parameter values are "available" to all cursors associated with a database connection. This is a real problem for us, because our application may have several active windows open, each using a bound parameter called "NAME" - there is no way to associate a parameter with a just single dynaset (aka cursor). Oracle's solution is to create several database objects (logon sessions). They claim that if you create a new database object with the same username and connect string as a previous one, then the two objects will "share" a single login. This worked correctly for the first two objects, after that we started getting a new login session for each database/dynset combination we created. Not a good thing!

We considered Power Objects and quickly turned it down because: 1) It's still in beta
2) It only supports OCX controls which currently are non-existent and won't be available until at least Windows 95 3) Their sorry-excuse for a scrollable "table" control is as bad as the one that comes with VB. I need something like Truegrid or one of the other good table controls on the market. 4) Power Objects is a complete development environment and is therefore quite complex. At such a level of complexity, it requires a pretty good sized user base to find problems and rally the provider to get them fixed or provide workarounds. VB has been hugely successful because of it's massive user base and the considerable experience Microsoft has with development products. I fear that the limited market that Power Objects will have will be insufficient to ensure a stable, bug-free, and resource-rich environment 5) Power Objects is completely datbase oriented, which is fine if MOST of what you want to do is database oriented. VB, however allows much more control over non-database oriented operations and allows a much more customizable user-interface.

Don't even think about Developer/2000!

Dave Trahan
dtrahan_at_ultranet.com Received on Wed May 24 1995 - 00:00:00 CEST