"Harry de Boer" <harry@staaf.nl> wrote in message
news:C5CEC37B-24B5-4022-A87B-4D2ECBC18B49@news.elevatesoft.com...
> Chris,
>
> It's not a logfile, but a generated table (for rental companies) that
> holds
> all possible departure info about their rental objects (mostly boats)
> which
> is used as a base for internet orders.
>
Is the start date a start-period for a boot rental and is this record
deleted after the boat is rented? Or with other words, what is
driving/triggering the amount of records of this tabel and is any startdate
in de past removed from it?

Second question is : Would the amout of records be smaller if the startdate
could be calculated be using a table based on hired dates instead?
Currently you have a list with all free slots. But could you not calculate
that all slots are free unless its in a list with taken slots?

Frans

Roy Lambert <roy.lambert@skynet.co.uk> wrote in
news:BF4E255D-BC68-4D19-A462-7B641F64DF0C@news.elevatesoft.com:

> The first thing I'd suggest would be a show the top 10 results and
> offer to show the rest with a warning that it might take a bit of
> time....

Or you could execute a SELECT COUNT(*) every time a user modifies some
filter data, and show the number of rows they are about to ask for.

The users will soon learn to estimate how long it'll take to send the list
(depending on each one's download speed), and improve their usage over
time, particularly as they are regular users.

--
Chris

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:DAF23CDD-171B-4CEE-9920-0F9FA02BB043@news.elevatesoft.com:

> Harry,
>
><< The time it takes to execute some of the involved SQL statements is
><< ... Locally it takes a couple of seconds.
>
> How long does the SQL take locally ?  IOW, is the majority of the time
> due to latency in the connection, or is the actual SQL processing time
> ?
>

Er, Tim, he just said "Locally it takes a couple of seconds."

-- Chris

Chris,

<< Er, Tim, he just said "Locally it takes a couple of seconds." >>

Sorry about that - sometimes I miss the most important sentences.

In that case Harry, it would seem to me that the latency is the main cause
of the delay.  Have you tried a similar SQL statement in DBSYS with the
Remote Tracing turned on (File/Options/Enable Tracing) ?  That will at least
give you an idea of where the majority of the time is being spent.

--
Tim Young
Elevate Software
www.elevatesoft.com

Frans,

The idea behind it all: generate a table where for all boats all possible
departure dates (and for every rental period -say week, weekend, etc)
information is stored (like price, harbour etc). This to provide internet
surfers selection mechanisms to see what boats are possible to rent.

I decided to use more -smaller- tables.

Regards, Harry


"Frans van Daalen" <Account@is.invalid> schreef in bericht
news:BEB3BA21-95F7-4067-B3EB-BFE63AF4AEE9@news.elevatesoft.com...
>
> "Harry de Boer" <harry@staaf.nl> wrote in message
> news:C5CEC37B-24B5-4022-A87B-4D2ECBC18B49@news.elevatesoft.com...
> > Chris,
> >
> > It's not a logfile, but a generated table (for rental companies) that
> > holds
> > all possible departure info about their rental objects (mostly boats)
> > which
> > is used as a base for internet orders.
> >
> Is the start date a start-period for a boot rental and is this record
> deleted after the boat is rented? Or with other words, what is
> driving/triggering the amount of records of this tabel and is any
startdate
> in de past removed from it?
>
> Second question is : Would the amout of records be smaller if the
startdate
> could be calculated be using a table based on hired dates instead?
> Currently you have a list with all free slots. But could you not calculate
> that all slots are free unless its in a list with taken slots?
>
> Frans
>
>
>

Thanks to all for sharing your knowledge and insights!

I decided to create a routine that generates from the mentioned table more
than one table (for example: a table that holds info about year/ month of
departure and possible rental periods, and so on). In a backoffice module
our customer can generate this tables. So, in this case the webapp requests
are faster. Less data goes over the net - the bottleneck in this story.

Thanks again, all!

Regards, Harry

"Harry de Boer" <harry@staaf.nl> schreef in bericht
news:F37FCAF9-B5E9-4858-ACEB-3270793C807C@news.elevatesoft.com...
> LS
>
> I have a table with 100.000+ records which is taking quite some time to
> process queries (requests are by browser to a intrawebserver with kbmmw
> middleware)? A lot of records contain the same info (generated). So I
wonder
> if there is a way to gain speed by creating another table(s) with maybe a
> different structure. The table structure below with some example data
shows
> that some records are the same (type/period/etc.)  except the ID, but not
> all! The records that are the same must be grouped somehow, but still have
> the possibility to know which ID's are involved. So, Is there a way of
> creating a better structure that results in smaller table(s) - in SQL?
>
> ID,TYPE,PERIOD,STARTDATE,HARBOUR
> "FOX (07)","Fox","wk",2006-09-02,"Terherne"
> "FOX (08)","Fox","wk",2006-09-02,"Terherne"
> "FOX (07)","Fox","wk",2006-09-04,"Terherne"
> "FOX (08)","Fox","wk",2006-09-04,"Terherne"
> "FOX (07)","Fox","wk",2006-09-06,"Terherne"
> "FOX (07)","Fox","wk",2006-09-07,"Terherne"
> "FOX (08)","Fox","wk",2006-09-08,"Terherne"
> "FOX (07)","Fox","wk",2006-09-10,"Terherne"
> "FOX (08)","Fox","wk",2006-09-10,"Terherne"
>
> Regards, Harry
> dbIsam 3.3, kbmMW 2.5+, IW7.18
>
>