procedure TForm2.Button1Click(Sender: TObject);
begin
  tbData.Edit;

  ltbTelephones.BeginCachedUpdates;
  ltbTelephones.MasterSource := dsData;
  ltbTelephones.IndexName := 'fkMasterID';
  ltbTelephones.MasterFields := 'RecordID';

  while not ltbTelephones.Eof do
    ltbTelephones.Delete;

  ltbTelephones.ApplyCachedUpdates;
  tbData.Post;
  edbTable1.Refresh;
end;

procedure TForm2.dbSessionLogin(Sender: TObject; var UserName, Password: string;
  var Continue: Boolean);
begin
  Username := 'Administrator';
  Password := 'EDBDefault';
end;

procedure TForm2.FormCreate(Sender: TObject);
begin
  edbtable1.Open;
  tbData.Open;
  ltbTelephones.Open;
end;

---

 Comments

---

The problem was that the primary key for the table was an IDENTITY column that was defined as GENERATED ALWAYS, and EDB was re-generating the IDENTITY column values when moving the rows into the cache. Thus, when the deletes were applied, the rows were not found due to the new IDENTITY column values.

---

 Resolution

---

Fixed Problem on 6/17/2010 in version 2.03 build 15

---

 Products Affected

---

ElevateDB LCL Standard with Source
ElevateDB VCL Client-Server
ElevateDB VCL Client-Server with Source
ElevateDB VCL Standard
ElevateDB VCL Standard with Source
ElevateDB VCL Trial