rlp@drutx.ATT.COM (Bob Prehn (@ The Right Choice)) (04/06/90)
We have had a problem using ENDRETRIEVE or ENDLOOP statements in EQUEL/C
Over the last 4 years!
RTI has been asked several times (both local and California) about this problem.But they have never done anything about it.
We have a number of situations that have only one match for a given search
and we want to terminate the search. (Some instances of having many allowable
values and we only want the first one.) The problem is that the next Ingres
statement dies with an KnReqLock or KnClrLock errors along with 9900 end of
file messages. The exact spelling of the errors may be different, since
it has been a while since I saw the message. (It is still a problem today,
Others in my group have had the problem.) The work-around is to not use the
endretrieve and suffer the performance penalty.
Is there soemthing else that can be done? I am tired of RTI's inaction!
Robert Prehn +-----------------------------------------------------------+
AT&T Bell Labs | ____ _______ _____ _______ |
Room 1E25 | / __ \ |__ __| / _ \ |__ __| |
11900 North Pecos | | <__> | | | \ \ \_\ | | |
Denver, Co 80234 | | __ | | | / \ __ | | THE CHOICE|
| | | | | | | | (\ / / | | |
drutx!rlp | |_| |_| |_| \_____/ |_| |
(303) 538-4554 | |
+-----------------------------------------------------------+bg0l+@andrew.cmu.edu (Bruce E. Golightly) (04/09/90)
I'm not sure I understand the problem. Can this be addressed using a
REPEAT RETRIEVE? If you are only interested in the first row of a set,
then there is no particular reason to enter the retrieve loop, as indicated
by the ##{ - ##} pair. By using a REPEAT, you incur most of the performance
penalty the first time the statement is executed, from then on , performance
is considerable better. I use this technique in some of my applications, so
I know it works.
On a larger scale, though, the problem still exists. Trying to terminate a
retrieve loop pre-maturely has some of the same characteristics of having
a program fail badly. You are left with an assortment of temp-files lying
about that have to be cleaned up by doing a RESTOREDB or PURGEDB. This is
a more serious problem because of the disk usage.
###############################################################################
!
Bruce E. Golightly ! bg0l@andrew.cmu.edu (BeeGeeZeroEl)
Chief of Data Base Development ! (412)268-8560
Telecommunications Group !
Carnegie Mellon University ! UCC 117, 4910 Forbes Ave.
! Pittsburgh PA 15213-3890
Vice President, Western Penna IUA !
###############################################################################jkrueger@dgis.dtic.dla.mil (Jon) (04/10/90)
rlp@drutx.ATT.COM (Bob Prehn (@ The Right Choice)) writes: >We have a number of situations that have only one match for a given search >and we want to terminate the search. (Some instances of having many allowable >values and we only want the first one.) [and INGRES's ENDRETRIEVE isn't] ... >The work-around is to not use the >endretrieve and suffer the performance penalty. [or is there another way] You call yourselves The Right Choice. But your database programming consists of taking the first choice. See any inconsistency there? How about qualifying the thing you're looking for to singleton select? Worse case is the max or min of a type, performance will be no worse than fetching all and throwing all but one out. Best case is finding a natural range that uniquely identifies an acceptable row. Of course, there are reasons why this might be difficult, in which case ENDRETRIEVE is the right tool. I wish I could help you there, but we've never seen it fail. Can the problem be replicated? -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Drop in next time you're in the tri-planet area!