At 02:38 PM 4/3/96 GMT, John Painter relied to a message from Chuck Meeker:
<snips>
 
>Connecting to the existing Image databases was a problem at first.
>Access was extremely slow using the HP API because it didn't recognize
>the existing Image search keys.  The serial reads were dragging down
>performance.  Third party solutions would solve that, but we didn't like
>the prospect of being forced to include the cost of third party software
>with every new installation.  Now with the Express 3 patch, the search
>keys are recognized and performance is quite satisfactory on a properly
>sized box.  Even so, it will take some work on your part to get the
>Image database set up through the Allbase runtime DBEs and all the rest
>of the drivers on the clients.  For some reason, despite the best
>efforts of HP's Kriss Rant, there is little technical support behind the
>marketing hype from HP.  Bottom line: it can be done and it does work
>pretty well, but the process is still a struggle.
 
<PLUG>
As one of those "Third Party solutions"
 
One of the advantages of the ODBC API is that it is a plug and play
interface.  The beauty is that if a client application codes to the ODBC
API, then their code should work with any ODBC implimentation.  While we at
M.B. Foster are proud of the extensions beyond the ODBC API that we offer to
our clients (for example, ability to call host based intrinsics), we are
careful to point out that they are indeed extensions and that by using them,
you are breaking the plug-and-play aspect of the ODBC API.
 
The challenges that are pointed out regarding the intelligent use of
intimate knowledge of the underlying platform (in this case, the simple fact
of recognizing keys) during access optimization have nothing to do with
conformance to the ODBC API but are, rather, something that I would think
you should expect from any ODBC driver vendor on any platform.  Our support
of Image keys (for the past 2 years), KSAM, MPE files and Powerhouse
dictionaries is completely transparent to the client user (except, of course
for the obvious speed and functionality advantages).  Our timely adoption of
32bit client support (shipping for several months now) is further example of
the advantages that can be gained by a 3rd party vendor who specializes in a
specific area of the marketplace.
 
While we would be thrilled if everyone used our ODBCLink drivers, we
understand that some people would prefer to pay for their ODBC API support
in installments (the performance and functionality price).  The ODBC API
gives application vendors the opportunity to code to the ODBC API standard
and then let the customer chose how they wish to pay for their driver
implimentation.  There is no need to be "forced to include the cost of third
party software with every new installation", you can let the customer
decide.  Of course, we would be pleased to discuss how an application vendor
might incorporate an OEM version of ODBCLink into their own product to gain
yet another competitve edge.
 
For more information about ODBCLink, call 1-800-ANSWERS.
 
</PLUG>
 
 
Brian Duncombe ([log in to unmask]) - M.B. Foster Software Labs
"Inside every large program is a small one struggling to get out."
          C. A. R. Hoare