>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...
Alas, buried inside SetRange is SetCursorRange, which calls
CheckProviderEOF before the "real" SetRange call (FDSCursor.SetRange).
>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.
Erk! Virtual OO Collections? Iterators? And just when I thought I
sort of understood Interfaces. :) Are these CORBA constructs?
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: Myles Penlington [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 10, 1999 11:14 AM
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: Efficient searching in TClientDataSet
>
> 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
application/ms-tnef
