[Javascript] Timing Issues

[Mike Dougherty]

Our intranet uses a server-side cache to store the results that could
take up to 15 minutes to retrieve from the SQL server.  The data is
presented in user-defined pages from 1 to 500 records at a time, with
first/previous/next/last and direct record number addressing.  Once the
eyeballing is done online, the user can click the export button to
retrieve a TAB delimited text file for easy import into Excel for use in
a pivot table or other analytic tool.  (why reinvent the pivot table,
when Excel does such a good job already?)

For the management types who just want to print a report, we serve
Crystal reports over the intranet via the crystal web control - this
solution does the number crunching on the server, allows
paging/drill-down/etc. and prints exactly as IT-serviced crystal reports
(rather than the ugly HTML print IE gives you)

For really serious number crunching analytics, consider giving your
user(s) a real database management package. <g>

-----Original Message-----
From: javascript-bounces at LaTech.edu
[mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
Sent: Monday, July 21, 2003 12:56 PM
To: [JavaScript List]
Subject: Re: [Javascript] Timing Issues


*This message was transferred with a trial version of CommuniGate(tm)
Pro*
Excellent notion.  However, I'm also betting that people want to "see"
the
output before they commit it to a table for reporting to the CEO.

I'll be sure to make the 'table-storage' download feature very
prominent, in
hopes it takes some of the heat off the other bits...

-- Dave Lovering

----- Original Message -----
From: "Roger Roelofs" <rer at datacompusa.com>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Monday, July 21, 2003 10:21 AM
Subject: Re: [Javascript] Timing Issues


> Dave,
>
> How about creating a separate link to allow the user to download the
> data to an xml or text file.  If they want to do reporting I'm betting
> they are pasting/importing into a spreadsheet or reporting tool
anyway.
>
> Roger,
>
>
> On Monday, July 21, 2003, at 01:10  PM, David Lovering wrote:
>
> > Dear Chris:
> >
> > All good ideas.  Unfortunately, in the former iteration I did have
> > paging --
> > and got complaints from folks who wanted to print entire tables for
> > reports
> > without segmentation issues getting in the way of the layout.
Business
> > majors -- go figure.
> >
> > Although I'm certain the 'table per row' solution would work, the
> > overhead
> > would be extremely gruesome, and I'll hold that trick in reserve
until
> > I've
> > exhausted everything else in the bag.
> >
> > Have you any experience with createElement to "grow" an already
> > displayed
> > table?  How does this affect the background latency to load the
whole
> > table?
> >
> > The 'response.flush' feature might indeed work, particularly if I
can
> > force
> > the event handler to act on it after the "build" of each record.
> > Of course, since the screen geometry is set by "worst-case" TD
> > widths/heights, the whole screen will jitter like a hornytoad on a
> > hotplate
> > as differing field lengths come pouring in.  Hmmm... some testing is
in
> > order.
> >
> > -- Dave Lovering
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
>


_______________________________________________
Javascript mailing list
Javascript at LaTech.edu
https://lists.LaTech.edu/mailman/listinfo/javascript