Given that the HP "IMAGE/SQL and Client/Server Tools"
Video Teleconference is coming up day after tomorrow,
I would like to pre-submit some issues that our site feels
are important to expanding the success of Image/SQL in
the real-world client/server (C/S) environment.  Hoped to
to have this done earlier, but you know how it goes........
 
Note that not all of this may fit exactly under the first five
subject areas listed in the teleconference brochure;  if
not, figure everything fits under the sixth and last area;
i.e:  "Your Questions".......    If I get a chance, I will try and
ask about some of this during the teleconference.  If not
there, I guess next opportunity will be at the SIGIMAGE
meeting at IPROF-95 on Wed 5 April.........    Anyway, :
 
Over the last few months Fred White published a series
of five articles in the Adager Column in the HP Chronicle,
which provided a very detailed technical analysis of some
of the weaknesses in the current implementation of the
Image/SQL utility IMAGESQL.PUB.SYS.  Fred has also
collected some of his thoughts in this area in a paper
titled "Migrating to IMAGE/SQL";  he was good enough
to send me the October 94 revision.
 
Fred's paper is 10 pages, and I suggest that anyone who
is contemplating doing any serious work with Image/SQL
should read it.  Fred raises some important points that
need to be addressed to maximize the usability and
success of Image/SQL in the real world. My experience
in going through an initial Image/SQL setup to get Q+E
going leads me to concur with a lot of the things Fred
pointed out (note my experience is several months old).
 
Of course the HP SQL Database Lab is working hard
on a lot of stuff right now, so HP may have already
addressed some of the things Fred pointed out; maybe
we will get an update on this during the teleconference
on Friday.
 
I'm not going to try and review all the points Fred went
through in his articles and in his paper;  he already did
that a lot better than I can.  It does seem clear that for
all but trivial databases and very basic client-server
(C/S) systems, successful implementation involves a
lot more than just ATTACHing your Image database to
a DBE.  And it seems like a lot of the sites that would
like to get into C/S with Image/SQL will want to add
SQL access features to existing complex systems.
 
So the overall process of installing Image/SQL both on
the PC and the 3000 needs to be as simple and as
automatic as possible, whether there are a handful of
users or 16,000 like at the U. of Notre Dame.  Any place
that requires repeated manual entry of user names,
passwords, or etc. that are already known to the system
somewhere really needs to be fixed.  Should be options
for wildcards, user access classes, auto-load names,
etc. wherever possible.  Plus there needs to be a better
integrated cookbook (PC + 3000) for doing all of this:
completing the installation process and then doing on-
going maintenance of the whole C/S system.
 
A few specific comments:
 
1.   Fred mentions that Image - SQL naming differences
which can result in two Image fields with the same
item name and data type having different SQL column
names in different mapped tables is to be avoided.  At
almost all costs, I would think;  a guaranteed confusion
factor.  Seems to me that if possible Image/SQL should
always give clear warnings if a user asks it to do stuff
like this.  Ala Jurassic Park:  just because we can
doesn't mean we should;  or want to, for that matter.
 
2.   Since SQL just loves the "_" (underscore), maybe
elevating an enhancement request on the SIGIMAGE
wish list to include underscores in Image names is in
order.  Confess have no idea how difficult this would be.
 
3.   If HP is indeed considering other additions to the
data type and size capabilities that Image/SQL will
support besides E2's and E4's, hopefully once they go
to the trouble of changing it they will include as many of
the currently unsupported Image data types as
possible the first time around, like Z28 and P28.
 
4.   Being able to automatically maintain integrated
control and synchronization of ALL the interdependent
files which may now be involved when ATTACHing
Image database(s) to DBE(s) is critical.  Unless I'm
missing something, there still appear to be deficiencies
in this area.
 
Summaries of some of the Image/SQL design flaws
that Fred pointed out.  They seem like real flaws to me:
 
1.   Column name and type mappings should be
performed database-wide, not just at the dataset level.
 
2.   Attached databases should be able to share a
set of users.
 
3.   The Image/SQL requirement to enter the Image
access class password for each user name entered
should be changed.
 
4.   DISPLAY USER should list users in alphabetical
order and allow display of sub-groups.  Looking through
a non-ordered list of 5000 users is not very appealing.
 
5.   The requirement to provide and the resulting
logging in various places of various passwords and
maintenance words is a clear security risk.
 
6.   The ability to ATTACH databases from various
accounts and volume sets to DBE's in other accounts
and volume sets is a recipe for chaos as far as trying
to keep everything in sync.  If you crash and have to try
and recover, you may well regret doing stuff like this.
 
7.   There needs to be a facility for quiescing a DBE and
all of its attached databases, short of kicking all users
off the machine.
 
FINALLY, a couple things Fred did not touch on in his
paper:
 
1.   When the HP Database Lab posted their customer
survey to this list a couple months ago, they did not
include a question on whether B-tree access should be
at the Image intrinsic level or only through SQL.  I
suggested they add the question and re-issue the
survey.  Guess that didn't happen;  in any case:  It is
critical that integral Image B-trees be done at the
intrinsic level, NOT just through SQL, IMNSHO.  I hope
HP will ask this question at the teleconference, if it is
set up to do electronic voting like I guess it's supposed
to be.
 
2.   Windows95 may indeed turn into Windows96, but it
will really be real one of these days.  So hope HP does
not wait to start working on 32-bit ODBC drivers that
can be used with Image/SQL until Microsoft has sold a
couple million copies of Windows9X.
 
3.   Even before Windows9X, we are running WFW on
all our PC's.  Does the Image/SQL ODBC driver do
WFW yet ??
 
4.   What is the current read on the prospect for getting
both DDL and DML support in Image/SQL ??
 
========================================
Ken Sletten                                    Tel:  206-396-2525
NUWC Division Keyport             Fax: 206-396-5183
Code 3312, Building 894
Keyport, WA  98345
[log in to unmask]
========================================