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.