TDataset im editmodus durchsuchen

[MyRealName]

Hallo,

ich wollte mal sehen ob es eine Möglichkeit gibt, das folgende einfach zu tun :

Sagen wir ich habe ein Dataset mit einem Integerfeld (in Wahrheit sind es 3 Felder, tut aber nichts zur Sache, will nur vermeiden, dass Vorschläge wie "Nimm eine Generic list" kommen). Ich will vermeiden, dass eine Zahl doppelt reinkommt, arbeite mit CachedUpdates, kann also nicht durch SQL in der DB nachfragen.
Kann man irgendwie beim "BeforePost" prüfen, ob der Wert schonmal eingegeben wurde ? Das Problem ist ja, dass ich im Editmode bin und nicht einfach den Cursor verschieben kann. Dazu müsste ich ein Post machen, dann bookmark nehmen, durchsuchen und dann wieder hinspringen und in den EditMode gehen. Geht das einfacher ?

In einer Präsentation vor 1 oder 2 Jahren zu einem Preview einer neuen Delphi Version habe ich mal gesehen, dass man dataset in forin-Schleifen durchsuchen lassen kann (in der Zukunft damals) und kein TDataset.Next mehr ausrufen muss und das ging dann auch in einer Kopie automatisch, so dass die Cursorposition nicht geändert wird. Kam dazu mal was raus ?
Oder geht das über Cloned Cursor (mit denen habe ich nie gearbeitet)

Danke schonmal
MRN

[himitsu]

Hmmm, Locate kennst bestimmt ... TDataSet.Lookup suchst zwar "ohne" Scrollen, aber ich glaub das scrollt dennoch, nur ohne eben die Events auszulösen.


Nain.
Offiziell kommst nur durch Scrollen an andere Felder/Datensäte und dabei geht das Edit verloren,
aber du kannst ja mal in den Protected-Property ala "Buffers" nachsehen (Typen TRecBuf, TValueBuffer, TRecordBuffer, ...), aber darfst dann auch die Werte selbst dort rauskopieren. (die vorhandenen TField-Instanzen greifen ja nur auf die aktuelle Zeile zu)

Nja, man könnte zwar auf die internen Daten/Records zugreifen, aber dafür kenn ich jetzt es keine direkten API/Funktionen und praktisch kann/tut jeder Komponentenentwickler bei seinem Dataset die Daten anders speichern.
Und das TDataSet selber hat noch garkeinen Speicher.


Speichern, dann suchen und bei Fehler wieder zurück geht auch nicht so gut, weil dann beim Cancel wieder die neuen (falschen) Daten im Record stehen.
Bzw. im BeforePost das Alte merken (Field.OldValue, wird quasi autormatisch im BeforEdit kopiert), dann speichern, suchen, bei Fehler das Neue/aktuelle merken, das Alte wieder rein und speichern, Edit wieder öffnen und die neue Kopie zurück ....... wenn du das jetzt verstanden hast, dann darfst es gern so machen. :stupid:

[p80286]

Warum läßt Du das nicht die DB machen?Die sollte das eigentlich können.

Gruß
K-H

[hoika]

Hallo,
Unique Index drauf
und mit einer 2. Query separat suchen

[haentschman]

Moin...:P

Zitat:

und mit einer 2. Query separat suchen

+1 :wink:

[hhcm]

Zitat:

Zitat von haentschman (Beitrag 1457731)

Moin...:P

Zitat:

und mit einer 2. Query separat suchen

+1 :wink:

Zitat:

arbeite mit CachedUpdates, kann also nicht durch SQL in der DB nachfragen.

-1 ? :stupid:

[haentschman]

Zitat:

arbeite mit CachedUpdates, kann also nicht durch SQL in der DB nachfragen.

...das gilt nur die aktuelle Query. :stupid: Eine separate Query, vorzugsweise dynamisch erzeugt, holt sich die Menge für die Prüfung. :wink:

also... +1 8-)

[jobo]

(Ganz weit im Hinterkopf)
Gab es nicht sowas wie (virtuelle) Dataset Kopien?
Dort könnte man das vielleicht prüfen.

[TigerLilly]

ClientDataset hat eine Clone-Methode, die für sowas gut ist.

Unique-Index auf das Feld (die Felder) + du bekommst beim Posten einen Fehler, wenn der Wert schon da ist.

Du bekommst die Werte, die in der Query stehen ja von irgendwoher - hol sie dir 2x ab + du kannst in der 2ten Instanz beliebig suchen.

Du bekommst die Werte, die in der Query stehen ja von irgendwoher - schau dort nach, ob es den Wert schon gibt.

Bevor(!) du editierst, hol dir die daten, die dich interessieren in eine andere Struktur + validiere dort.

Lass die Datenbank den Fehler entdecken.

Benutze was anderes, das beim Post nicht gleich in die DB schreibt - zB wie die ClientDatasets.

[Uwe Raabe]

Zitat:

Zitat von MyRealName (Beitrag 1457712)

Oder geht das über Cloned Cursor (mit denen habe ich nie gearbeitet)

Das wäre auch mein Ansatz, aber probiert habe ich das auch noch nicht.

Zitat:

Zitat von haentschman (Beitrag 1457734)

Zitat:

arbeite mit CachedUpdates, kann also nicht durch SQL in der DB nachfragen.

...das gilt nur die aktuelle Query. :stupid: Eine separate Query, vorzugsweise dynamisch erzeugt, holt sich die Menge für die Prüfung.

Eine solche Query berücksichtigt aber nicht die noch im Cache liegenden neuen Records.

[MyRealName]

Zitat:

Zitat von Uwe Raabe (Beitrag 1457739)

Zitat:

Zitat von MyRealName (Beitrag 1457712)

Oder geht das über Cloned Cursor (mit denen habe ich nie gearbeitet)

Das wäre auch mein Ansatz, aber probiert habe ich das auch noch nicht.

Jo, da muss ich mal ein wenig mehr suchen dazu.

Zitat:

Zitat von Uwe Raabe (Beitrag 1457739)

Zitat:

Zitat von haentschman (Beitrag 1457734)

Zitat:

arbeite mit CachedUpdates, kann also nicht durch SQL in der DB nachfragen.

...das gilt nur die aktuelle Query. :stupid: Eine separate Query, vorzugsweise dynamisch erzeugt, holt sich die Menge für die Prüfung.

Eine solche Query berücksichtigt aber nicht die noch im Cache liegenden neuen Records.

Genau da liegt das Problem.

Das mit dem Index im TDataSet kann ich auchmal probieren, hört sich interessant an.

[haentschman]

Zitat:

Eine solche Query berücksichtigt aber nicht die noch im Cache liegenden neuen Records.

...ok, ok. Daran hatte ich nicht gedacht. :?

[MyRealName]

Hier die Lösung, welche ich im Endeffekt programmiert habe :

Code:

procedure TForm1.qryDataBeforePost(DataSet: TDataSet);
var
  ADataSet: TFDMemTable;
  bCanPost : Boolean;
  StartDate1, StartDate2, EndDate1, EndDate2 : TDate;
begin
  StartDate1 := qryDatagueltigab.AsDateTime;
  EndDate1 := qryDatagueltigbis.AsDateTime;
  bCanPost := True;
  ADataSet := TFDMemTable.Create(Self);
  try
    ADataSet.CloneCursor(qryData);
    ADataSet.First;
    while Not ADataSet.Eof do
    begin
      StartDate2 := ADataSet.FieldByName('gueltigab').AsDateTime;
      EndDate2 := ADataSet.FieldByName('gueltigbis').AsDateTime;
      if ((DateInRange(StartDate1, StartDate2, EndDate2)) Or (DateInRange(EndDate1, StartDate2, EndDate2))) then
      begin
        bCanPost := False;
        Break;
      end;
      ADataSet.Next;
    end;
  finally
    ADataSet.Free;
  end;
  if Not bCanPost then
  begin
    MessageDlg('Fehler im Gültigkeitszeitraum', mtWarning, [mbOk], 0);
    Abort;
  end;
end;

Ich hoffe, es hilft jemandem, der mal ein ähnliches Problem hat :)

[himitsu]

Alternativ ohne CachedUpdates und mit einer Transaktion um alles.
Da kannst dann mit dem zweiten Query in der selben Transaktion in der DB suchen, weil die ja schon alles kennt.

[MyRealName]

Zitat:

Zitat von himitsu (Beitrag 1457763)

Alternativ ohne CachedUpdates und mit einer Transaktion um alles.
Da kannst dann mit dem zweiten Query in der selben Transaktion in der DB suchen, weil die ja schon alles kennt.

Ja, aber wir haben halt diesen expliziten Speichern Button, an den ich mich klemmen muss. Und dann müsste ich entweder die Transaction (um beim Speichern dann das Commit zu machen) sehr lange offen lassen oder aber eben ChachedUpdates nutzen.

Es funktioniert ja jetzt, vielen Dank an alle :)