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

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.

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

Gruß
K-H

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

Moin...

Zitat:

und mit einer 2. Query separat suchen

+1

Zitat von haentschman:

Moin...

Zitat:

und mit einer 2. Query separat suchen

+1

Zitat:

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

-1 ?

Zitat:

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

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

also... +1

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

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.

Zitat von MyRealName:

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 von haentschman:

Zitat:

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

...das gilt nur die aktuelle Query. 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.