Have you tried using SetRange()? Don't know how it works in this case, but
It **may** be better,
then it may be okay for locate to still have that line of code, but thinking
about it further the scroll bars on the grid may then give the wrong
impression ... compromises compromises and more compromises...
This is where I really like Virtual OO Collections and Iterators to solve
this kind of problem cleanly (and fast) - goes hand in hand with CORBA.
Myles.
> -----Original Message-----
> From: Carl Reynolds [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 10, 1999 10:53 AM
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: Efficient searching in TClientDataSet
>
> Thanks Peter (and Myles) for your help, but I guess you're trying to solve
> a different problem. The full story is quite a mouthful, so I've held
> back from explaining my setup so far - I guess I should go into more
> detail.
>
> Without delving too deeply into why, I have a "listbox" of "customers" and
> an associated "grid" of "orders", and in some cases the orders grid might
> display all, or almost all, orders for ALL customers. I realise that this
> is not often desirable, but it's up to the user. The user does have the
> option of filtering on the data at any point, but there are valid cases
> for them wanting to see everything.
>
> So, it's a single tier setup, but ClientDataSets are used as they have a
> lot of useful functionality - for example, constructing indexes on the fly
> so that the data in the grid can be ordered by calculated fields - click
> on a column and it orders by that column, that sort of thing. In
> addition, when a query with a very large result set is executed, using a
> ClientDataSet makes navigating "nicer" in look and feel - once a certain
> set of records is loaded, browsing among that set is very quick, as
> opposed to browsing against a query, where paging up a page is just as
> slow as paging down. This is even without discussing maintenance issues.
>
> It's this last case, where we have a large result set of all orders for
> all customers, which interests me. In this case, we want to accept the
> default ordering of orders grouped by customers. The user always has the
> option of loading in all the records into the ClientDataSet, eg. by
> dragging the scrollbar on the grid down to the bottom, but under some
> circumstances this might cause quite a wait. More likely, the user might
> wish to move down to view the orders of a particular customer.
>
> It's this moving down in the grid which I'm trying to do as economically
> as possible - cache the records for all customers down to the customer
> clicked on, and no more. Unfortunately, the behaviour of
> ClientDataSet.Locate is to immediately fetch all the records into its
> cache and then to do a search on the appropriate fields. And moving
> through the clientdataset record by record, until you find the record you
> want, is very slow indeed. So I ended up modifying
> ClientDataSet.LocateRecord, as discussed in my last email, and now it does
> do what I want. The code's not perfect (mainly because I fear what
> GetRecordForKey might actually be doing behind the scenes!) but I haven't
> found a better solution yet and tests so far have worked quite well.
>
> What you suggested, and what Myles suggested before you, are totally valid
> if you're doing things in a three tier situation. In that case you'd want
> to avoid the situation that I've described anyway - you would try to
> insist on quite a stringent filter being applied before ever loading down
> any records to the client. Performance between the middle tier and the
> database would dwindle into insignificance compared to the considerations
> of data transfer over your WAN. So I appreciate your sensible advice, and
> I don't wish to seem ungrateful, I just didn't explain myself properly!
> :)
>
> Anyway, enough rambling (deep breath :).
>
> Incidently, should discussions of Queries and ClientDataSets really be
> under DUG-DB? Or is that just SQL related stuff?
>
> Cheers,
>
> Carl Reynolds Ph: +64-9-4154790
> CJN Technologies Ltd. Fax: +64-9-4154791
> [EMAIL PROTECTED] DDI: +64-9-4154795
> PO Box 302-278, North Harbour, Auckland, New Zealand
> 12 Piermark Drive, North Harbour Estate, Auckland, NZ
> Visit our website at http://www.cjntech.co.nz/
>
> -----Original Message-----
> From: Peter G Jones [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 10, 1999 8:42 PM
> To: Multiple recipients of list delphi
> Subject: Re: [DUG]: Efficient searching in TClientDataSet
>
> If you are using a cds locally (no server) then presumably you are doing a
>
> loadfromfile so you will always have all the records in memory. If not,
> then you should do your search on the server via the provider.datarequest.
>
>
> >From: Carl Reynolds <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
> >Subject: [DUG]: Efficient searching in TClientDataSet
> >Date: Wed, 8 Sep 1999 13:02:32 +1200
> >
> >When I do a Locate on a TClientDataSet, it immediately loads all
> >remaining records into its buffer, ignoring PacketRecords. The same
> >thing happens when using FindKey or GotoKey. If I don't want to have
> >all the records loaded automatically (because I have a very large result
> >set), is there a more efficient way to locate a record than to step
> >through one record at a time, checking each for a match?
> >
> >Cheers,
> >
> >Carl Reynolds Ph: +64-9-4154790
> >CJN Technologies Ltd. Fax: +64-9-4154791
> >[EMAIL PROTECTED] DDI: +64-9-4154795
> >PO Box 302-278, North Harbour, Auckland, New Zealand
> >12 Piermark Drive, North Harbour Estate, Auckland, NZ
> >Visit our website at http://www.cjntech.co.nz/
> ><< attach3 >>
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
> --------------------------------------------------------------------------
> -
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
