In a message dated 95-11-25 23:06:21 EST, [log in to unmask] (Denys Beauchemin)
writes:
 
>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
>through 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 are in the early stages of testing the access of data in existing
TurboImage databases. I have converted 6 databases into one database
environment and have also done all of the required field updates and splits.
 These mappings are recorded in batch files so that we can detach and rerun
the mappings when we reattach.
>
>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?
>
 
We are accessing the data via the ODBC using Visual Basic.  I am using SQL
passthrough to create snapshots and I have also used this method to pass
update and delete SQL statements as well as to execute stored procedures
which I created in the DBE.  I  am executing queries against several
databases and I am thrilled with the results so far.
I have run one test with an existing VB app using Paradox 4.0 tables which I
implemented earlier this year.  3 of the Paradox tables are created by
extracting data each night from the HP databases.  The extracted files are
then downloaded and imported into the paradox tables.  I have replaced the
downloaded data  and the need for the paradox tables with 3 SQL statements!
 
>Question 3. If you are not now currently using IMAGE/SQL with SQL, why not?
>
Planning for more vigorous testing to begin soon and hoping to begin a phased
implementation in 96.
 
>Question 4. If you are using attached IMAGE/SQL databases with SQL but are
>not doing client/server access, why not?
>
>See, there is something for everyone in these questions.  Now, let us not
>waste time arguing what qualifies as client/server or trying to define it or
>anything like that, let s just get some feedback going here.