Gentle Listers,
 
Here is the long awaited second part of the IMAGE/SQL ATTACH saga.
Again the disclaimer, if you are not interested in using IMAGE/SQL in a
client/server environment or do not wish to attach an IMAGE database to an
ALLBASE DBE, read no further.
 
As you remember, the original message was about the fact the mainstream DB
tools are incapable of recording and subsequently re-applying splits and
update types on compound items.  I explained where this lack bit me, and will
bite you too in due time.  Towards the end of the original posting, I
explained that the problem was compounded by the addition of managing the
views created on the IMAGE tables.
 
I received quite a bit of private email and I now it is time for the
continuation of the story.
 
Before going any further, though, I must point out I have created a tool,
almost 3 years ago, which is able to record and re-apply the splits and
update type of compound items as well as other items.  So the issue is not
one of  _can't be done_ but rather one of _why hasn't it been done everywhere
else_.  Further, last year I added the view capture facility in DBTSQL, so it
can be done.  I created DBTSQL because I saw a need for it.  It is not my
main business, it is more of an intellectual exercise.  I have sold a few
copies, and I keep it up to date, but we do not advertise it beyond the
flyers at the various shows, sometimes.  I have a few other goodies like
that, such as a jumbo dataset detail reorganization utility which I wrote
last year, just to see what it would look like.
 
 
In a message dated 95-11-11 14:11:28 EST, [log in to unmask] (Leslie-Anne
Bain) writes:
 
>When you issue a DETACH command in IMAGESQL.PUB.SYS, an SQL "DROP TABLE"
>statement gets issued for each data set (mapped table).  A side effect of
>a DROP TABLE is that all views and authorities (i.e. GRANTS) associated
>with the table (and views) are also dropped.
>
>You can use SQLGEN.PUB.SYS to save the information that will be dropped.
>SQLGEN is described in the ALLBASE/SQL Database Administation Guide
>(36216-90005).
>
>Use the "GENERATE VIEWS" command to generate a file that has CREATE VIEW
>statements for one or more views that you are interested in.  You can
>either generate all views in the DBE, all views for a particular owner,
>or one or more specific views.
>
>Here is an example using musicdbe which sends the definitions of all views
>in the DBEnvironment to a file called "myfile":
 
<BIG SNIP>
 
 
>You can edit the file so that it only contains the SQL statements that
>you are interested in.  When you are ready to recreate the views (after
>you have reattached to the DBE, do the following:
>
>isql=>connect to 'musicdbe';
>isql=>set echo on;             <---to echo commands to your display
>isql=>start 'myfile';          <---to execute the SQL in 'myfile'
>
>This isn't the best example because MUSIC.SELECTIONS_A_V0 is actually
>a view created by IMAGE/SQL itself, but you should be able to get the
>idea.
>
>Hope this helps,
>Leslie-Anne
 
 
Leslie-Anne, this helps a great deal, but perhaps not in the way you thought.
 Yes, it is possible to manage an attached environment in the way you
describe, but it is kludgy at best and error-prone and complex at worse. You
illustrate my point exactly, one should not have to do it that way.  This
should be built into the mainstream DB tools such as DBChangePlus. This is
what your maintenance dollar is supposed to buy.
 
If DBChangePlus for example, is unable to extract, store and the recreate the
views when it does maintenance on my database, then I have been wasting my
maintenance money on DBChangePlus for the last 3 years.  It has been over 3
years since IMAGE/SQL has been released.
 
One of the biggest problems, and to my mind, the biggest problem with
IMAGE/SQL in a client/server environment, is the management of the beast.
 Fred White has expended much toner (1990's ink) in pointing out the various
problems with IMAGE/SQL.  I am now pointing out the various problems with the
DB tools with regards to attached databases.
 
Let's recap the ones I have experienced so far:
 
1- Will not keep updates and splits of compound items.
2- Will not keep updates for mode for creator access.
3- Will not keep user-created views of IMAGE tables.
 
Of course, at this time there are few users of IMAGE/SQL with attached
databases.  The number grows however, and shortly other people will run into
the same problems I have with the mainstream DB tools.
 
By the way, for those of you that say.  Geez, what's the big deal, why didn't
he use is own tool that day and shut up about it.  Well, I didn't use my
tool, because the customer was using a mainstream tool, of which he had the
very latest version.  I thought that by that time, the mainstream tools would
be up to par with regards to the attached databases.
 
I thought wrong.
 
 
Kind regards,
 
 
Denys. . .
 
P.S.  Stay tuned for part trois.