Scrolling Cache

Nancy Tietz ntietz@mcare3.med.umich.edu
Thu, 13 May 1999 12:53:41 -0400


Yes! More pre-defined items as suggested below would be great!  
As for the duplication of records at the end of the cache... I remember
having a hard time with that when the records looked very similar to each
other.
nt
-----Original Message-----
From: Chris Sharman [mailto:Chris.Sharman@ccagroup.co.uk]
Sent: Thursday, May 13, 1999 12:29 PM
To: Bob.Deskin@Cognos.COM
Cc: Chris.Sharman@ccagroup.co.uk; powerh-l@lists.swau.edu
Subject: RE: Scrolling Cache


>1) When you scroll forward to the END of the cache or the last record - it
>should display a message similar to if you try to scroll backwards to the
>beginning of the cache ("Limit for backwards scrolling reached"). Not sure
>why Cognos doesn't do this.

I guess for consistency with the old behaviour, which is worth quite a lot
in
my view.

>2) When displaying the last "n" records, don't fill the page (thereby re
>displaying previously displayed records). Instead display it the same as if
>you did not have cache turned out. Since you can scroll backwards, you can
>always do that if you want. But the way it is now, the users think they
>have transactions "duplicated".
>Terry Pickering                         CompuGroup, Inc.

Our users have never had a problem with this 'duplication', although they
did
request the display of "1-8/11" or similar.
I suspect you could detect & flag the 'duplicated' records using the pre &
postscroll procedures. I wouldn't like to lose the present behaviour,
although
(obviously) I wouldn't mind an added option.

>I too would be interested in hearing specific ideas on the caching
>"problem". Has anyone used caching with users that are not already
>
>As for specific enhancements and messages, please let me know. No promises
>but you never know :-)
>Bob Deskin              

Once the cache overflows (easily done with just 255 records), the display of
"n-m/255" is misleading. How would we detect that the cache was now, say,
11-265 of 265 (or more) on the file, rather than just continuing to display
our position within the cache, ignoring the records logically before & after
the cache ?

As has been discussed here before, displaying "1-8/11" involves a tedious
amount of procedural code added to each screen. PH is a 4GL, so it ought
really to handle this for us. I'd like displayable predefined items such as:
	number-cached		The number of items presently in the cache
	first-displayed		The first displayed occurrence within the
cache
	last-displayed		The last displayed occurrence
	first-cached		The number of the first cached record within
				the found set (ie one more than the number
of
				records scrolled out of the cache).
Obviously there are other numbers: total-records-found, last-cached,
number-displayed, etc, all of which have a simple arithmetic relationship to
the ones I've defined. I've no strong views on which should be predefined
and
which should be left to us to define, but I'd be inclined to say the more
predefined the merrier, since it should be as simple as possible to display
screen position: ideally just field statements with maybe a define or two.

Another suggestion: lazy find (done now by modifying the find procedure to
say
'for displayed' rather than just 'for'). Invaluable, especially on selects
which pick relatively few records. Users need a cache (when they're on
"autoscroll" and go past the screenful they wanted), but don't need to wait
to
fill the cache (possibly reading the whole database) when the first match
was
the one they wanted. Maybe NOLOOKAHEAD on the file statement ?

Regards, Chris
______________________________________________________________________
Chris Sharman			Chris.Sharman@CCAgroup.co.uk
CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.