At least how ODBC can be faster than direct to Image.  We are using
ODBC/32, MiddleMan and FrontMan from Minisoft.  Frontman can use either
ODBC or MiddleMan for direct to image.  Consider the case of wanting to
load up a state table from an image database.  If I use direct to image,
then each DBGET mode2 is a new call from the client, sent to the server,
data is returned.  With ODBC the SQL statement will buffer up the data on
the HP and write it back in hopefully one chunk.  This is way faster.
However if you were to just go into query and do the serial read, you would
probably win.

shawn





John Zoltak <[log in to unmask]> on 12/30/98 09:24:17 AM

Please respond to John Zoltak <[log in to unmask]>

To:   [log in to unmask]
cc:    (bcc: Shawn Gordon/IS/FHM/FHS)
Subject:  Re: Report writers- suggestions?




Joe Geiser wrote after Ken Sletten wrote:

> The Europeans are so far ahead of the US and Canada in adopting ODBC
for the
> HP3000 by the way, and they are deploying projects at a dizzying pace.
Why
> are the Americas so far behind?  Comfort (with their HP3000 and their
ways
> of doing things), Price (why pay for something when I can get it free
-
> remember, you get what you pay for, in most respects), and Resistance
to
> Change (Image/SQL over "TurboIMAGE" -- see below).  Folks in Europe
have
> crossed this hurdle already and we're still grappling with it.

Using this logic (you get what you pay for) means that when Image was
unbundled from the operating system, we got more value out of it? Just
because something comes bundled with the operating system or other
subsystem doesn't mean we didn't pay for it.

Why throw out a working application for something else just because that
something else is new and cool? Maybe the Europeans are "deploying
projects at a dizzying pace" because they are starting from scratch. We
in the US, as early adopters usually end-up somewhat behind because you
just can't afford to throw-out everything and start over just because
the next wave comes along. It's like trying to buy that new stereo
system every year, you just can't keep up.

> I can show how Image/SQL is as fast, if not FASTER, than Direct to
Image.
> Sure, give it the "query from hell" and they ALL will slow down,
Direct to
> Image, or via Allbase.

Ok, let's see! That FASTER part amazes me. Just considering the layers
that it has to go through would make me think that Image/SQL has to be
slower.

It's been a few years since I've tried that Image/SQL thing. Back then
there were too many things that didn't work right or weren't supported.
All these things add up to a point where it wasn't worth it for me to
use considering the extra work on maintaining all the DBE's.

I've considered trying the ODBC connection. But most of my users treat
everything like flat files anyway, so all of this is lost on them. They
don't know the difference between Access and Excel.

All of this is not to say that I don't use the new-fangled tools. I
still use VB and VC++, but I use a home-grown Image/Mpe connection and
it's fast.

Maybe I'll give Image/SQL and ODBC a try anyway. But I like to know in
what cases Image/SQL is faster that direct to image.

John Zoltak
North American Mfg Co