QualityCentral

Public Report

Report From: Delphi-BCB/Midas/TClientDataSet [ Add a report in this area ]

Report #: 2019

Status: Closed

nested CDS Edit/Post twice, master ApplyUpdates, Delta incorrect

Project: Delphi

Build #: 6.240

Version: 6.0

Submitted By: Dave Rowntree

Report Type: Basic functionality failure

Date Reported: 8/6/2002 9:14:23 AM

Severity: Commonly encountered problem

Last Updated: 10/6/2006 6:50:45 AM

Platform: 95, 98, 2000, NT, XP

Internal Tracking #: 143384

Resolution: Fixed (Resolution Comments)

Resolved in Build: : 9.0.1761.24408

Duplicate of: None

Voting and Rating

Overall Rating: (5 Total Ratings)

4.40 out of 5

Total Votes: 1

Description

This problem was found by vavan.

The problem only occurs when the DSP has poPropogateChanges set, and at least one DeltaDS field NewValue is updated in the DSP.AfterUpdateRecord event.

If you (Edit and Post) more that once to a nested CDS, then call cdsMaster.ApplyUpdates, no update error is returned, but the cdsMaster Delta is not cleared, and the cdsMaster ChangeCount is > 0.

A subsequent cdsMaster.ApplyUpdates call will fail with 'record changed by another user'.

Steps to Reproduce:

Download, compile and run the zip'd demo app from Attachments. Follow the on screen steps.

Workarounds

If you always use ApplyUpdates(0) , you can do the following to avoid having ChangeCount greater than 0 :

  with ClientDataSet do
    if (ApplyUpdates(0) = 0) and (ChangeCount <> 0) then
      MergeChangeLog;

Attachment

nestedposttwiceupdatefails.zip

Comments

Vladimir Ulchenko at 8/6/2002 11:18:40 PM -

... and subsequent cdsMaster.CancelUpdates call fails with 'Operation not applicable' in my case ...

Matt Hamilton at 1/7/2004 3:33:19 PM -

Is this bug still present in D7? I have been having many problems with rows posted to my database more than once (playing havoc with inventory etc) from a master/detail nested TClientDataSet arrangement.

Dave Rowntree at 2/2/2004 8:11:33 AM -

If the problem had been fixed, the report would be closed, the 'Resolution' would say 'Fixed', and the 'Resolved in Build' field would contain an entry. We were asked to log QC bugs against the first version containing the fault, hence the D6 classification.

Dave Rowntree at 5/11/2004 2:54:18 AM -

Fixed in Midas.dll

Dave Rowntree at 6/15/2004 12:02:47 PM -

Re-Opened (D7.0.8.1)

The problem still exists. A new testcase has been attached to the internal report.

Quality Central

Developer Tools

Database Tools