Denys Beauchemin <[log in to unmask]> wrote:
 
>During the January 20th TCU broadcast, I mentioned that you could attach an
>IMAGE database to the same DBE using the WITH USER= parameter for the
>ATTACH command.  Evan Rudderow called earlier this week to point out that
this is
>incorrect.  IMAGE/SQL does not permit the same database to be attached to
the
>same DBE more than once.  It is documented in the IMAGE/SQL administration
>guide on page 4-4.
 
<<snip>>
 
>At some point in the past, while discussing the problem of overloaded
>datasets with several people, the idea of multiple attaches was put forward
>with the idea that one could do different SPLITS on each attach.  This is
>totally unworkable.  For overloaded datasets where the data is of the same
>type, like CHAR, one can use views with subsets. If the data is if
differing
>type for different record type, you are out of luck.
 
The question I've got is, "Will we always be out of luck as regards
overloaded datasets?"
 
I haven't given this a great deal of thought, but...
 
If we were given the capability of coping with overloaded data sets there's
a choice of where to do the coping: (1) in Allbase (specifically creating
views in ISQL) or (2) in IMAGESQL.
 
Creating views in ISQL is probably NOT the way to accomplish this: multiple
views of a table -- views which redefine a column as being of different data
types -- strikes me as something that violates whatever SQL 'standards'
there are.
 
That leaves IMAGESQL.  Basically the user would need more complete, and
finer, control of the ATTACH; one would be able to:
 - Specify datasets which should not be attached
 - Specify datasets which should be attached multiple times; these would not
be differentiated by having different owners, but by being mapped with
different table names.  Overloaded data sets (especially those with other
that character (CHAR) data could then be split to our hearts content.
 
 
This capability probably isn't critical to IMAGE/SQL's success, in fact it
doesn't even affect me -- I don't have any databases with overloaded
datasets which I want to access through IMAGE/SQL.  But I have spoken with
people at other sites for whom this IS a problem; perhaps someone could
undertake a survey to determine how many sites would benefit from the
ability to deal with overloaded datasets.
 
 
Since the topic is vaguely IMAGESQL SPLITs, I've got a question:
We've got this application that's got one really weird field in a detail
data set (I don't know whether it was the programmer or Powerhouse who
decided to save eight bytes by doing this):  the field is called
WEEKLY-HOURS and is defined (as far as IMAGE is concerned) as X24 (I'd have
defined it as an 8Z4).  The application, however, sees it as 8Z3 (more
specifically the application sees eight occurrences of S99.9).
 
Anyway, we ATTACH this database to a DBE and when we look at WEEKLY-HOURS we
see something like:
     00}00}00}00}00}00}00}00}
 
Not much you can do with that except try to explain to the users what all
those squiggly worms are...
 
I tried splitting this is various ways; usually I succeeded in getting an
ATCERR 32426 (Invalid mapping -- go to Jail, go directly to Jail, do not
pass Go, do not collect $200) although I seem to recall once being able
SPLIT the source (as an X3) to a DECIMAL(3,1) which did in fact map, but the
decimal places were screwed up.
 
Anyone out there every seen one of these before?  Anyone ever beat it?
 
Fortunately the person who was responsible for this design no longer works
here, so I can blame him all I want; unfortunately I can't cut his fingers
off for having done this.
 
 -- evan