Tim:
I've done things like that before, with an OLAP database that basically
didn't have a reporting tool. The trick (for the way I did it anyway) was to
have the next/prior buttons basically run a new query, but one with
specified limits (e.g. parameters) that would return a given group or number
of records. The awkward part is specifying in terms of a query what the page
size should be. Another approach is to read all the records on the server
side, return "x" of them for the first page, then use session tracking to
"feed" the remaining records to the client: e.g. he hits the "next page"
link, it calls the same servlet that does NOT do a new query, simply gets
whatever the next page of records is & sends it along. Only problem with
that approach is the amount of memory you might have to have on the client -
not sure it would scale too good.
>From what you say I think approach #1 (new queries each time) might work
best.
Mike
Javacorporate Ltd
http://www.javacorporate.com
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of T.
Anderson
Sent: Thursday, September 02, 1999 11:10 PM
To: [EMAIL PROTECTED]
Subject: Re: A tough one ?
Guys,
As you've stated it worked like a champ. Thanks a million!
On the issue of caching...
Have you tried inserting the key to the "next/prior" set of records on the
next/prior button at the top or bottom of the page? I'm about to dive into
a
solution to this very problem and was looking for an efficient approach.
I'm developing a web based reporting system to replace the current
Crystal/VB
Solution. One of the requirements was drill down capability and with a
broad
date range does in fact yield an unreasonably large result set.
Thanks again for the solution!
Regards,
Tim
Michael Nash wrote:
> Guy:
>
> I can definitely confirm that netscape waits for a </table>. Apparently IE
> doesn't. I had this same problem with the HTML logging portion of Expresso
> (our app framework). Solved it by the paging technique, effectively
> archiving to a "old" area whenever the log gets too big, and with flush()
on
> the output stream as well.
>
> Mike N
> Javacorporate Ltd
> http://www.javacorporate.com
>
> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Zerbe
> John W
> Sent: Thursday, September 02, 1999 8:20 AM
> To: [EMAIL PROTECTED]
> Subject: Re: A tough one ?
>
> Are you pumping out more than 1k records to a single html table? I believe
> that netscape (or any browser that I know of ) will wait till it gets the
> </table> before trying to render any part of it. If this is the case, you
> may want to look at ending the table after every 50-100 records.
Personally,
> I'd rather see you only send 100 or so at once and build in logic to cache
> the result set somewhere and let your browser user page forward & back to
> view it.
>
> John Zerbe - Mellon Bank
> IM&R - Middleware Team
> Phone: 412-234-1048 E-Mail:[EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: T. Anderson [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, September 02, 1999 12:09 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: A tough one ?
> >
> > I've started having difficulties with this as well. I too am reading
from
> > a
> > result set and have setup a counter to
> > allow a periodic out.flush() but so far to no avail. When reading less
> > than
> > 1000 records the servlet functions perfectly. When reading more than
1000
> > records Netscape locks up tighter than a drum. (e.g. task mgr. kill)
> > Tomorrow I'll try adding a wait to allow the stream to flush as the loop
> > is a
> > little tight.
> >
> > Recently read something about "multi-response" servlets that addressed
> > this
> > issue but have not yet researched.
> >
> > Please post back if/when you find a solution and I'll do the same.
> >
> > Regards,
> >
> > Tim
> > JRun 2.3 152 w/Java 2
> >
> > Nic Ferrier wrote:
> >
> > > I don't know much about websphere but I presume it's just a servlet
> > > environment.
> > >
> > > You can do this by using an autoflushing Writer, eg: PrintWriter
> > > created with autoflush boolean set to true.
> > >
> > > The ouput sent to the PrintWriter will then be constantly flushed out
> > > and sent to the client.
> > >
> > > Beware though! Some servlet engines might ignore flushing and only
> > > output once the stream has been closed.
> > >
> > > You might need to set the content-length.
> > >
> > > This trick will also likely stop you from taking advantage of
> > > HTTP/1.1 features like Chunked-Encoding.
> > >
> > > Nic Ferrier
> > > Tapsell-Ferrier Limited
> > > http://www.tapsellferrier.co.uk
> > >
> > > "Use Ockham Luke"
> > >
> > > >>> Guy Nirpaz <[EMAIL PROTECTED]> 9/1/99 9:14:14 PM >>>
> > > Hi all,
> > > I'm developing a three tier application. I'm using the IBM Websphere
> > > as
> > > the application server.
> > > The data which I get from the DB comes (in this is a must) in small
> > > portions and very fast.
> > > I would like to know if there is a way to start showing the results
> > > on
> > > the screen as soon as the first portion of data arrives from the DB
> > > and
> > > continue to concatenate the other portions without the user to
> > > intervene.
> > >
> > > Hope I'm clear about that,
> > > Thanks
> > >
> > >
> >
__________________________________________________________________________
> > _
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > > of the message "signoff SERVLET-INTEREST".
> > >
> > > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > > Resources:
http://java.sun.com/products/servlet/external-resources.html
> > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
__________________________________________________________________________
> > _
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
