ClientDataset: Wie Record verschieben oder Position tauschen

[p80286]

Zitat:

Zitat von Jumpy (Beitrag 1337782)

Nur aus Neugier, warum würde man sowas machen? Kann man nicht einfach den Datensätzen eine Positions-ID oder so geben und diese ggf. tauschen? Oder hab ich falsch verstanden, worum es geht (die Anzeige)?

Nun ich denke daß Harry, da er eine "einfache" Lösung bevorzugt, im Dataset herumfummelt, damit die Anzeige seinen Ansprüchen genügt. Das widerspricht zwar jeder Trennung von Daten und Anzeige aber dieser Lösungsweg ist für Datensensitive Komponenten wohl der offensichtliche.

Gruß
K-H

[himitsu]

Die Grids von Embarcadero sind Schrott (vorallem VCL) und können so einfache Dinge nicht, wie z.B. das Sortieren und Filtern ... da muß man das dann im DataSet machen (besser aber schon im Query, bevor es im DataSet landet).

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1337791)

Die Grids von Embarcadero sind Schrott (vorallem VCL) und können so einfache Dinge nicht, wie z.B. das Sortieren und Filtern ... da muß man das dann im DataSet machen (besser aber schon im Query, bevor es im DataSet landet).

Würde die Anzeige in einem "normalen" Grid gemacht, und würden die Daten von der Query zum Grid mit z.B. einer Liste transportiert, dann könnte man diese Liste unterwegs so durch die Mühle drehen, daß man seine eigenen Daten nicht mehr wiedererkennt, wenn man will.

Zitat:

besser aber schon im Query

Auf jeden Fall der richtige Ort um die Daten so aufzubereiten (sortieren), wie man sie gerne von der DB bekäme. Denn für das Verarbeiten größerer Datenmengen sind DB#s im allgemeinen prädestiniert.

Gruß
K-H

[TRomano]

Himitsu hat schon Recht mit den Emba-Grids.
Die DB-Admins sehen es nicht gerne, wenn bei jedem Klick auf ein Header des DBGrid eine neue Query (mit neuer Sortierung) vom Server abgerufen wird. Das gibt Traffic ...
Dann lieber die Abfrage in einem ClientDataSet mit verschiedenen Indexen definieren und dieses dann nach jedem Header-Click mit dem entsprechenden Index "sortieren". Sollte dann alles lokal ablaufen.

[Harry Stahl]

Zitat:

Zitat von p80286 (Beitrag 1337789)

Zitat:

Zitat von Jumpy (Beitrag 1337782)

Nur aus Neugier, warum würde man sowas machen? Kann man nicht einfach den Datensätzen eine Positions-ID oder so geben und diese ggf. tauschen? Oder hab ich falsch verstanden, worum es geht (die Anzeige)?

Nun ich denke daß Harry, da er eine "einfache" Lösung bevorzugt, im Dataset herumfummelt, damit die Anzeige seinen Ansprüchen genügt. Das widerspricht zwar jeder Trennung von Daten und Anzeige aber dieser Lösungsweg ist für Datensensitive Komponenten wohl der offensichtliche.

Gruß
K-H

Wäre natürlich auch eine Möglichkeit, einen quasi User-sortierbaren Index hinzuzufügen. Diesen Index müsste ich aber auch speichern. Müsste also das Format der "Datenbank" (=einfache StringList, mit Feldtrennzeichen getrennt) ändern. Das wollte ich aber nicht aus Gründen der Rückwärtskompatibilität. Klar, könnte jetzt noch verschiedene Verrenkungen machen, um das alte Dateiformat bei der nächsten Installation des Programms durch das neue Datenformat der Datei zu ersetzten.

Aber warum sollte ich das machen, wenn es auch so geht.

Ich hatte hier in gewisser Hinsicht den Ansatz einer nicht sortierten Stringlist im Kopf, wo man ja auch per .exchange oder .move die einzelnen Zeilen / Datensätze an andere Positionen verschieben kann.

Ein Problem bezüglich Trennung von Daten und Anzeige sehe ich bei meinem Ansatz übrigens nicht. Denn es werden ja keine Daten im Grid gespeichert, ich ändere nur die unter dem Grid liegende Datenschicht, die Anzeige im Grid passt sich automatisch an.

Da es im vorliegenden Fall auch nur um eine lokale Verwaltung eines kleinen Datenbestandes geht, keine echte Datenbank dahinter liegt (benutze nur ClientDataset und Datasource) und somit auch keine Client-Server Abfragen oder ähnliches erforderlich sind, sehe ich hier kein Problem.

Lasse mich aber gerne eines Besseren belehren.

[Uwe Raabe]

Zitat:

Zitat von Harry Stahl (Beitrag 1337833)

Diesen Index müsste ich aber auch speichern. Müsste also das Format der "Datenbank" (=einfache StringList, mit Feldtrennzeichen getrennt) ändern. Das wollte ich aber nicht aus Gründen der Rückwärtskompatibilität. Klar, könnte jetzt noch verschiedene Verrenkungen machen, um das alte Dateiformat bei der nächsten Installation des Programms durch das neue Datenformat der Datei zu ersetzten.

Den Index musst du gar nicht speichern. Beim Laden der Datenbank aus der Datei wird das Indexfeld einfach hochgezählt und beim Speichern gibt die Reihenfolge des Index ja die Reihenfolge der Datensätze vor.

[Harry Stahl]

OK, ich müsste aber manuell den Index-Filter verwalten, wenn ich z.B. per Drag & Drop eine Zeile an eine andere Position verschiebe, z.B. von 100 auf 4. Oder? Das wäre wieder zusätzlich Aufwand. Würde ich ja machen, wenn ich einen zusätzlichen Nutzen bei dieser Lösung erkennen würde.

Das Speichern vom ClientDataset in die Stringlist mache übrigens wie nachfolgend. Habe ich hier evtl. typische Anfängerfehler drin, bzw. geht es einfacher?

Z.B. würde mich interessieren, muss ich immer erst den Filter ausschalten, um wieder die volle Anzahl der Records zu bekommen oder gibt es eine andere Variante, um durch den ganzen Datenbestand zu iterieren?

Delphi-Quellcode:

procedure TF_ConvertList.SaveClientDataSetToStringList;
var
  L, x, c, current: Integer; s: string;
  Filterstatus: Boolean;
begin
  current := cds1.RecNo;
  cds1.DisableControls;

  FilterStatus := cds1.Filtered;
  cds1.Filtered := false;

  try
    cds1.MergeChangeLog;

    c := cds1.FieldCount;
    slProp.Clear;

    cds1.First;

    for L := 0 to cds1.RecordCount-1 do begin
      S := '';
      for x := 0 to c-1 do begin
        if x = c-1 then begin
          S := S + cds1.Fields[x].Text;
        end else begin
          S := S + cds1.Fields[x].Text + #1;
        end;
      end;
      slProp.Add(S);
      cds1.Next;
    end;

    slProp.SaveToFile(CurrentFileName);

  finally
    cds1.EnableControls;
  end;

  cds1.Filtered := FilterStatus;
  if Current <> -1 then cds1.RecNo := Current;
end;

[Uwe Raabe]

So ist es meiner Meinung nach etwas einfacher.

Delphi-Quellcode:

var
  current: Integer;
  Filterstatus: Boolean;
  fld: TField;
  linelist: TStringList;
  datalist: TStringList;
begin
  current := cds1.RecNo;

  FilterStatus := cds1.Filtered;
  cds1.DisableControls;
  try
    cds1.Filtered := false;
    cds1.MergeChangeLog;
    datalist := TStringList.Create;
    try
      linelist := TStringList.Create;
      try
        linelist.Delimiter := #1;
        linelist.StrictDelimiter := true;
        cds1.First;
        while not cds1.Eof do begin
          linelist.Clear;
          for fld in cds1.Fields do begin
            linelist.Add(fld.Text);
          end;
          datalist.Add(linelist.DelimitedText);
          cds1.Next;
        end;
      finally
        linelist.Free;
      end;

      datalist.SaveToFile(CurrentFileName);
    finally
      datalist.Free;
    end;

  finally
    cds1.Filtered := FilterStatus;
    cds1.EnableControls;
  end;

  if Current <> -1 then cds1.RecNo := Current;
end;

[Harry Stahl]

@Uwe: Danke für die Optimierungshinweise.

Mit anderen Worten, es gibt keine einfachere Variante, um auf die Datensätze innerhalb des Clientdataset zuzugreifen. Ist jetzt kein Drama, aber wenn es eine Möglichkeit gegeben hätte, wäre es gut, das zu wissen.

[jaenicke]

Noch einfacher wäre es nur, wenn das Dateiformat nicht vorgegeben wäre. Wir benutzen einfach die integrierte Methode zum Speichern und Laden von XML Dateien. Das hat den angenehmen Nebeneffekt, dass auch die Feldinformationen schon automatisch dabei sind usw. und es ist eben nur die eine Zeile Quelltext jeweils.