Convertion of TTable to TClientDataSet causing delay in showing records
Subhajit Ghosh
I'm replacing all TTable datasets with ClientDataSet in an application to
implement multi tire technology.
It caused delay of opening a table having 300000 records. As i want avoid
using of tables, is there anyway to access the table with huge number of
records. Although there is no such difference in speed between table and
clientdataset when opening small no of records.
Any suggestions will be appreciated.
TIA
Subhajit.
Daniele Teti
Can you use PacketRecord property?
Daniele
AVAUX
there is some design issues.
With CDS by default, all record are fetched from DB, thus you have two
solutions :
- limit the number of record by retrieving only the usefull records
- use packetrecord to incrementaly fetch records (but if you need random
record, this is useless)
But 300k records is deraisonnable, even for superman it is a lot of record
to analyse ;) , often you can reduce the amount of data and only displays
the usefull records.
"Daniele Teti" <daniel...@hotmail.com> wrote in message
news:Xns92E87CB55A4EAda...@207.105.83.65...
Subhajit Ghosh
Avaux & Wayne raised the correct point as i was thinking about of changing
the design of the application.
But the problem is i need to stick with the current design like opening a
form with a dbgrid and table with 300k records haa to be open using
"table.open" within formcreate event.
All records are useful, there is really no other criteria to ignore any of
them.
My purpose is simply the conversion of database from Paradox to Interbase
keeping the screens design intact. In case of most of the forms it's
implemented with "table.open" manner and it worked fine when it was in
paradox. Now i'm converting to interbase and the requirement is, the
application will also run from multiple terminal connecting a same database
as the system using BDE alias. That's why i tried to implement
Clientdataset.
Anyway it seems that i should utilise PacketRecord property to solve this
issue at the most.
Thanks and regards.
Subhajit.
"Wayne Niddery [TeamB]" <wnid...@chaff.aci.on.ca> wrote in message
news:3e00930f$1...@newsgroups.borland.com...
> "Subhajit Ghosh" <subhaji...@cogentech.co.in> wrote in message
> news:3e00...@newsgroups.borland.com...
> > I'm replacing all TTable datasets with ClientDataSet in an application
to
> > implement multi tire technology.
> > It caused delay of opening a table having 300000 records. As i want
avoid
> > using of tables, is there anyway to access the table with huge number of
> > records. Although there is no such difference in speed between table and
> > clientdataset when opening small no of records.
>
> Avaux has already identified the correct issue, I just want to emphasize
it.
>
> If you are going multi-tier (or even just standard C/S) you must rethink
the
> design of your application, there is no valid reason to ever need to
display
> 300,000 records - or even just 3,000 - in an application. There is nothing
> useful a user can do with such numbers. ClientDatasets are the right thing
> to use at the client side, the problem is how you are doing things on the
> server side.
>
> You do not mention what database you are using, but in most cases you
would
> want to use a proper SQL-based database (i.e. not Paradox or Access) and
use
> only SQL queries to retrieve records. You then need to makes sure users
> cannot see *any* records without entering some search criteria which you
> will form into an SQL Where clause.
>
> --
> Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
> RADBooks: http://www.logicfundamentals.com/RADBooks/delphibooks.html
> "The only reason some people get lost in thought is because it's
unfamiliar
> territory." - Paul Fix
>
>
Wayne Niddery [TeamB]
>
> Avaux & Wayne raised the correct point as i was thinking about of changing
> the design of the application.
> But the problem is i need to stick with the current design like opening a
> form with a dbgrid and table with 300k records haa to be open using
> "table.open" within formcreate event.
> All records are useful, there is really no other criteria to ignore any of
> them.
How can 300K records be "useful" all at the same time to someone looking at
the screen? Your users may say they need to see all this but that is only
because they can't imagine any other way being easier - this is what they
are used to. I've been involved in enough conversions from legacy apps to
new SQL apps to be able to say with confidence that such users, while they
may have to be led and may initially complain, will invariably get used to
the new way to browse records and most will come to like it *better*. If
they can enter characters in an incremental search, then they can enter the
same characters and hit a Search button that only brings back matching
records.
You say there is no criteria to ignore any, but the users must have *some*
way to find the exact records they need to work on at any given time. Are
you saying the only way to find a record is to page up and down through 300K
until they happen to see the one they need? Are these records ordered in
some way? If so then they can be *limited* the very same way (at the very
least).
Subhajit Ghosh
onfilterrecord events of dataset rather clientdataset now.
But until you open the dataset, filterrecord event doesn't execute. So in
this condition clientdataset.open fetched all 300k records first then
filters depending on the value. This example is for browsing records.
There is also other forms where filter event is used but again you need open
that table first and then system will do some calculations based on filtered
records.
Ultimately we can't change the source code to convert the database. Only
thing we are doing is changing table component to clientdataset as i
mentioned earlier that the application will run under network. To convert
from table to CDS i faced the problem of spped and posted the question to
the newsgroup.
Althrough the system style of filtering records is implemented but that
doesn't make any difference of decreasing the speed as everytime we need to
open the dataset first.
I think the architechture of the system is now clear to you. Any more
suggestions will be appreciated.
regards.