>Homer Godwin@CENTIGRAM asked the Subject question:

Based on the text of this message, and Bob Walker's reply, it sounds to me
like two questions:  1)  Is Image/SQL ready, and 2) is ODBC ready?  A brief
answer is They both work and performance is usually reasonable.

Another brief answer:  It depends on the use you plan to make of them
(increased functionality vs. "empowerment").  This, more than the
mechanics, is the subject of my reply.  Now the long[er] explanation.

I have never heard it recommended that one should replace Image INTRINSICs
with Embedded SQL calls *in programs that run on the HP3K*, for ANY reason.
  If there are batch jobs or even OLTP programs that run on the 3K,
continue using Image.  I don't mean to imply that one shouldn't use an
RDBMS.  I'm
simply saying that if you're using Image, USE IMAGE!  Also, if the 3K is
your platform, take advantage of it.

Image/SQL is most useful when you want access to Image from another DBMS or
platform.  Another DBMS usually means Relational DBMS.  Another platform
usually means a "client" [PC or MAC].  In both cases, one needs
"middleware" to connect to Image.  Image/SQL is one of the pieces.

If one needs the added functionality of accesing Image via some other DB,
then one makes that decision, possibly taking into consideration some of
the points listed below.

ODBC is middleware that allows PC/MAC clients to access a "data source".  A
data source could be flat files, etc., but it is most commonly used to
access Databases (as Homer and Bob point out).

One use Bob makes of ODBC and Image/SQL is to put a PowerBuilder front end
on an application.  This is a great use of the technology, whether building
new apps, or giving old ones a face-lift.  (On a side note, I believe data
drives a business.  There is no such thing as "Legacy Data" -- either a
business needs the data to operate or it doesn't.  There is such a thing as
a "Legacy Application" -- an application is comprised of the choices a
business made in programming language and other tools to "use" the data.)

Another use to which Bob puts the technology is allowing users the ability
to create ad-hoc reports (empowering the end-users).  This is conceptually
a great use of the technology.  Conceptually because there are a couple of
"gotchas".

Bob mentions both Excel and Access as tools used to create ad-hoc reports.
These are both very useful tools; Access in particular has a good Report
Wizard.  The "gotcha" is that both these tools can also be used to store
data.  In Excel, in fact, one *must* bring the data to the client before
doing any reporting/manipulating.

The questions are: Who is the "owner" of the data?  Is it OK to store the
same data in more than one place?  What happens if [when] the user changes
the data on the client instead of the server?  Even if the user changes the
data on the server, how often will the user want to update the data locally
(hourly, daily, weekly, after every update to the server)?

Another "gotcha" is that the tools Bob mentions allow update capability to
the server.  Access, with its Form Wizard, is of particular concern.  Using
these tools, a user could enter data that may not meet validation criteria
usually enforced by host-based applications.  The questions are:  Should
users update server data with "non-standard" tools/apps?  By what process
can users get these tools (in other words, can you be sure that only "super
users" or IS have these tools on their workstations)?

I'm not questioning the value of this technology nor any of these tools.
In fact we use this technology and these tools in our shop.  I would in
summary, however, ask:  Are you ready for Image/SQL and ODBC?

Carl Hughes