UNIQUE or not UNIQUE

[Deskin, Bob]

The only way to completely remove warnings without sacrificing some of the
added power PowerHouse gives you is to use NOWARN.

PowerHouse allows many "extensions" to IMAGE because when PowerHouse was
created on HP IMAGE was THE database and COBOL was the language. We wanted
to ensure that all (well, almost all) of those things you can do with IMAGE
and COBOL, you could do with PowerHouse and COBOL. While still dealing with
a 4GL of course. We wanted the developer to have a logical view of the data
while we took care of the physical view. However, knowing that the physical
is also important, we issue appropriate warnings.

So, for example, we allow substructures and redefinitions even though IMAGE
does not allow these. We also allow you to declare that a DETAIL index
(search item to use the IMAGE terminology) can be unique. Consider it as a
logical unique index rather than a physical one. And since the specification
in the dictionary is not something supported by IMAGE, we issue a warning to
the developer.

The specification of a unique index means that PowerHouse does all those
things it normally does for unique indexes. The only thing it can't do is
use QUTIL to create a unique physical index because IMAGE doesn't support
it. We generate the LOOKUP NOTON. But if you remove it, then there's no
check for uniqueness. We don't do anything at update time. The idea is to
validate the data on input rather than wait for the update.

In QUIZ and QTP, PowerHouse expects there to be only one record and reads
only one. It doesn't attempt to read more. In fact, this is an old (20 years
or so) technique to declare a DETAIL dataset twice, once with a repeating
index and once with a unique index. If you ever want just the first record,
use the unique definition.

Hope this helps.

Bob Deskin              
PowerHouse Web Product Manager
Application Development Tools, Cognos Inc.
bob.deskin@cognos.com
(613) 738-1338 ext 7268  FAX: (613) 228-3149
3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA


-----Original Message-----
From: Leonard_Berkowitz@harvardpilgrim.org
[mailto:Leonard_Berkowitz@harvardpilgrim.org]
Sent: July 9, 2001 8:34 AM
To: powerh-l@lists.swau.edu
Subject: UNIQUE or not UNIQUE




Yes, that is the question.

HPe3000, PH 8.19C

Last week I posted a question about why Powerhouse creates a UNIQUE index
for a
search item (key field) on a TurboImage detail dataset while at the same
time
*W*-ing that IMAGE does not support unique keys. Someone (I've deleted the
message, sorry) responded that an/the effect is that QUICK will GENERATE
code:
LOOKUP NOTON for that field.

I need to understand how PowerHouse in general treats the data when the
Index is
defined as UNIQUE even though the underlying DBMS does not support this.

1. OK, so QUICK will GENERATE the LOOKUP NOTON code. What if I delete that
code
from my screen source? Will the hidden procedural code still force a LOOKUP
NOTON? Yes, I do know how to see the procedural code, but I have no idea
which
screens may be relying on some non-self-evident feature of QUICK.

2. QUIZ and QTP: In establishing linkages to records with this value from a
higher-level file, will QUIZ and QTP just stop retrieving records because
the
Index is defined as UNIQUE? To take as an example line items of an invoice
where
the invoice number is the key from the master to the detail: will QUIZ/QTP
retrieve all of the line items with the common invoice number or a record
complex with just the first line item?

3. What other "gottchas" are there? In other words what are unexpected
results
where the PHD definition will override the data base structure?

This is part of an effort to remove all of the warnings that I can as part
of
compiling a PHD. I discovered a few detail datasets with UNIQUE indices. I
believe that most of them were just ignorance or careless cloning on the
part of
someone in hoary antiquity (well, four or five years ago), but there just
might
be one that was created that way intentionally. My own practice when I am
not
overyly lazy <grin> is to put a comment ad loc. whenever I do something that
is
unexpected or obscure enough that I had to research the issue myself. I've
discovered that I am the most frequent beneficiary of such comments, by the
way,
when I revisit the code months later -- or even after the weekend and I have
to
scratch my head about what the code contains.

It seems that the only *W*s that I cannot eliminate are the ones about the
item
being two small to hold all possible values. I can live with them as I can
live
with "Left truncation may occur" from the COBOL compiler.

Thanks.
===================
Leonard S. Berkowitz
Perot Health Care Systems
(Harvard Pilgrim Health Care account)
voice: 617-509-1212
fax:   617-509-3737
pager: 781-226-2431



= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.