It is a pity because some of the ideas implemented (or not ;-) in
ClientDatasets have a lot of potential. Fortunately I only need a subset of
that functionality and I have managed to code around most of the problems I
have encountered in my inherited version of TClientDataset.
David.
----- Original Message -----
From: "Myles Penlington" <[EMAIL PROTECTED]>
To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]>
Sent: Tuesday, November 21, 2000 5:23 PM
Subject: RE: [DUG]: Problems with CloneCursor
> There is enough bugs in TClientDataset that I am able to drive several
buses
> straight through the code - mostly in the MIDAS.DLL that are going to
force
> me to write my own version ... (In about 1 months time ...) - since we
don't
> have the source for the DLL. Pity. Most Borland code is okay, but the D5
> version of this cannot have been tested very well - or they chose to ship
it
> with the bugs (which looks like the case).
>
> The other alternative is to wait for D6 and see if the bugs are fixed -
> apparently the bugs still exist in the last beta release according to
> someone who paid for a Borland support call and tested against the beta
> available at the time.
>
> Myles.
>
>
> -----Original Message-----
> From: David Brennan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 21, 2000 5:12 PM
> To: Multiple recipients of list delphi
> Subject: [DUG]: Problems with CloneCursor
>
>
> I have a ClientDataset (let's called it cdsPayments) which the user is
> entering a list of records (payments) into. Sometimes while they are
> entering these payments the user will want to bring up a Find/List screen.
> This Find screen queries data related to payments and must exclude some
> records based on the ones the user has already entered.
>
> So I need a way of checking the records in cdsPayments without disturbing
> it's state (for example the user might be halfway through entering a new
> payment - I can't cancel or post this record for them). Obviously I can't
> directly use cdsPayments because I can't scroll it while it is potentially
> in edit mode. Similarly I don't want to maintain a seperate list of
payment
> details in a TList etc unless as a last resort.
>
> One solution which seemed promising was to use CloneCursor. This allows
> another clientdataset to have another cursor into the same data as
> cdsPayments. It works brilliantly - the Find form displays the correct
> details, cdsPayments remains in edit mode, destroying the Find screen and
> associated cloned cursor client dataset doesn't cause any problems etc.
>
> However from that point on running the command cdsPayments.Delete will
cause
> the cdsPayments to decide it is empty (EOF and BOF - although it still
> thinks it's record count is correct). I have tested a simpler case and it
> definitely seems to be triggered by calling CloneCursor.
>
> Has anyone had similar problems? How did you solve them? Or maybe someone
> has done similar things and not had any such problems? Either way I would
be
> interested to hear.
>
> Thanks,
> David Brennan
> DB Solutions Ltd.
>
>
>
>
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"