Board index » delphi » Paradox Performance

Paradox Performance

We are currently designing a database using Paradox and Delphi 3.
During our design, we have to come to realise that what we thought
would need to be several tables can in fact be only one. We have some
performance related reservations however.  The single table approach
may lead to a large number of rows being related to a single parent and
we are concerned that performance will sufer.  If the detail table were
to hold several thousand rows and need to select, say, 15 rows per master
row using the built in master/detail relationships within Delphi,
would the selection be particulary slow (slower than selecting the same
number of detail rows from several smaller detail tables)?  We would also
need to perform a further 'sub' selection based on which tab the user
had selected. I was thinking of using the filter property but would a
TQuery be a better choice?

Any help /advice would be greatly appreciated!

 

Re:Paradox Performance


With the volume of data you describe performance should be very fast.  For
sub selections of the detail records use a filter, not  a query for best
performance.

--
Bill

(TeamB cannot answer questions received via email.)
(To contact me for any other reason remove nospam from my address)

Re:Paradox Performance


Quote
Bill Todd (TeamB) wrote:
> With the volume of data you describe performance should be very fast.  For
> sub selections of the detail records use a filter, not  a query for best
> performance.

You mean "use Range" for best performance...

We're using SetRange for Table connections in our Apps. on Tables with more
than 200'000 rows over a network with approx. 20 concurrent users. Just
another remark: The network has been optimized adding a 100/10Mbps Switch Hub
between the Server and the user hubs - small workgroups of max. 8 ports are in
one collision domain. All users in one single collision domain will definitely
bring down your network (assuming the above config. and app.).

Kind Regards
Max

Quote
> --
> Bill

> (TeamB cannot answer questions received via email.)
> (To contact me for any other reason remove nospam from my address)

--

=======================
MBS Software Co., Ltd.
M.-Ph. Blickenstorfer
67/359 Mooban Tantong 5
Phuket 83000
Thailand
Tel : +66 76 242 516
Tel : +66 76 242 383
e-mail   :  m...@loxinfo.co.th
=======================

Re:Paradox Performance


Quote
Bill Todd (TeamB) wrote:
> With the volume of data you describe performance should be very fast.  For
> sub selections of the detail records use a filter, not  a query for best
> performance.

You mean "use Range" for best performance...

We're using SetRange for Table connections in our Apps. on Tables with more
than 200'000 rows over a network with approx. 20 concurrent users. Just
another remark: The network has been optimized adding a 100/10Mbps Switch Hub
between the Server and the user hubs - small workgroups of max. 8 ports are in
one collision domain. All users in one single collision domain will definitely
bring down your network (assuming the above config. and app.).

Kind Regards
Max

Quote
> --
> Bill

> (TeamB cannot answer questions received via email.)
> (To contact me for any other reason remove nospam from my address)

--

=======================
MBS Software Co., Ltd.
M.-Ph. Blickenstorfer
67/359 Mooban Tantong 5
Phuket 83000
Thailand
Tel : +66 76 242 516
Tel : +66 76 242 383
e-mail   :  m...@loxinfo.co.th
=======================

Re:Paradox Performance


No, I meant use a filter.  As I understood the message he was trying to
select a subset of linked detail records and you cannot use SetRange for
that. In any other case SetRange is definitely the right choice.

--
Bill

(TeamB cannot answer questions received via email.)
(To contact me for any other reason remove nospam from my address)

Other Threads