Denys et al,
 
>OK, question 1.  How many of you out there are actively using IMAGE/SQL
WITH
>SQL access?  Not just to say "We have updated to IMAGE/SQL," but rather,
"we
>have attached production databases and we are accessing the data in
IMAGE
>trough the SQL interface".  It doesn t have to be totally SQL, but a
least
>some portion of it, perhaps ad-hoc reporting, should be in SQL.
 
We don't use it yet. We are so busy, just keeping our heads above water,
that we dont get time to 'play'.
But we are going to have to use it, because we need to set up an WWW
server which will allow limited enquiries on the data, and ODBC seem to
be the way to go. Also we are looking t Impromptu/PowerPlay as an end
user tool.
 
>Question 2.  How many of you are actively accessing attached IMAGE/SQL
data
>via ODBC or other middleware in a client/server fashion to PCs?  How are
you
>doing it?  Which end-user tools (shrink-wrapped or otherwise) are you
using?
> Are you developing with VB or perhaps something else?
 
Every time I have got it to work, there has been some reason why I
abandoned it - too slow, too difficult, run out of time, or some other
reason. Right now, I can't get it to work with Windows 95 without the 16
bit ODBC drivers, and these seem to make Win.95 unstable.
Also, you need to stream a background job, and previously, I was able to
add the listener to my single background job that handles other annoying,
but necessary, background 'daemons'. (Why can't we have a type of job
that runs, but doesn't show or interfere with our normal jobs - maybe
even multiple job queues especially with the new multi processor boxes.)
 
>Question 3. If you are not now currently using IMAGE/SQL with SQL, why
not?
 
We use PowerHouse, and it gives us easy access to our TurboImage data
without SQL. (Of course, we could use SQL if we really wanted to :]).
 
Question 4. If you are using attached IMAGE/SQL databases with SQL but
are
not doing client/server access, why not?
 
Not doing this yet.
 
If ODBC connectivity to Image/SQL was a) intuitive, b) stable, c) fully
supported, d) easy to achieve and maintain (no DBE stuff, no background
jobs to be running, Win 95 32 bit seamless support) then of course we
would experiment and no doubt find a use other than a 'must have'.
 
Thanks
 
Neil Harvey
[log in to unmask]