Überprüfen von ID-Nummern

[Tharon]

Hallo!

Das OnExit-Ereignis ist nicht unbedingt ideal für derartige Prüfungen. Abgesehen von möglicherweise lange dauernden Prüfroutinen (vor allem, wenn hierzu Datenbankzugriffe erforderlich sind), welche vom Anwender als störend während der Eingabe empfunden werden, wird OnExit nämlich auch nur dann ausgelöst, wenn das Steuerelement tatsächlich verlassen wird (also den Eingabefokus verliert). Dies ist der Fall, wenn man per Tab oder Mausklick in ein anderes Eingabefeld wechselt, aber nicht, wenn z.B. zum Speichern ein Toolbar-Button angeklickt wird oder die entsprechende Tastenkombination (Shortcut) gedrückt wird! Fatal, wenn in diesem Fall wichtige Aktionen, die in der OnExit-Ereignisbehandlung implementiert sind, nicht ausgeführt werden...

Als Workaround kann man in den Aktionen wie Speichern o.ä. zu einem kleinen Trick greifen: man setzt einfach Self.ActiveControl auf nil, wodurch auf jeden Fall auch OnExit ausgelöst wird, selbst wenn der Eingabefokus nicht vom Anwender auf ein anderes Steuerelement gesetzt wurde!

Im folgenden Beispiel unterstelle ich jetzt einfach mal, dass Du eine Methode zum Speichern hast... ich nenne sie mal ActionSave

Delphi-Quellcode:

function TfrmAdrEdit.ActionSave(): Boolean;
var
  bOK:        Boolean;
begin

  bOK := True

  // Sicherstellen, dass alle OnExit-Ereignisse ausgeführt wurden!
  Self.ActiveControl := nil;

  { ... }

  // Hier folgt der Code zum Speichern der Eingaben

  { ... }


  Result := bOK;

end; // TfrmAdrEdit.ActionSave

Es ist aber gar nicht notwendig, noch während der Eingabe solche Prüfungen durchzuführen, es muss nur sichergestellt werden, DASS sie durchgeführt werden und zwar vor dem Speichern! Ein viel besserer und sauberer Ansatz ist es, grundsätzlich alle Gültigkeitsprüfungen (Validierungen) in einer zentralen Methode durchzuführen, welche dann vor dem eigentlichen Speichern aufgerufen wird. Das obige Beispiel würde dann so aussehen:

Delphi-Quellcode:

function TfrmAdrEdit.ActionSave(): Boolean;
var
  bOK:        Boolean;
begin

  bOK := True

  // Sicherstellen, dass alle OnExit-Ereignisse ausgeführt wurden!
  Self.ActiveControl := nil;


  // Gültigkeitsprüfungen
  if bOK then
  begin
    bOK := ValidateData();
  end;


  // Speichern
  if bOK then
  begin
    { ... }
  end;


  Result := bOK;

end; // TfrmAdrEdit.ActionSave


function TfrmAdrEdit.ValidateData(): Boolean;
var
  bOK:        Boolean;
begin

  bOK := True;

  // AdrNr noch nicht vorhanden?
  if bOK then
  begin
    // Hier folgt der Code zur Überprüfung, ob die eingegebene Adressnummer bereits
    // vorhanden ist

    { ... }

    // Wenn Adressnummer bereits vorhanden, Meldung anzeigen
    if not bOK then
    begin
      { ... }
    end;
  end;


  // ggf. weitere Gültigkeitsprüfungen
  if bOK then
  begin
    { ... }
  end;


  Result := bOK;

end; // TfrmAdrEdit.ValidateData

Eine andere noch bessere Möglichkeit ist es, Deine Prüfung im BeforePost-Ereignis der DataSet-Komponente unterzubringen, denn dort gehört sie eigentlich auch hin... :wink:

Ich hoffe jetzt mal, das war verständlich genug und ich konnte Dir damit helfen...


Noch was zum Thema Primärschlüssel und Auto-Werte:

Hansa schrieb bereits, dass hier offenbar eine Verwechslung stattfand... Und er hat völlig Recht, ein Primärschlüsselwert darf niemals an die Oberfläche gelangen, d.h. er darf dem Anwender weder angezeigt werden, noch darf er jemals geändert werden - das macht nur Probleme! Die Adress-ID oder Adress-Nr um die es hier geht, kann also nur ein Sekundärschlüssel sein, d.h. ein zusätzliches Feld, welches eben auch eindeutig ist.

Ausserdem sollten auch grundsätzlich keine AutoInc-Felder verwendet werden, auch das macht früher oder später nur Probleme (s. auch Antwort von fiasko)! Etwas besser sind da schon die Generatoren/Sequenzen, wie sie bei richtigen Datenbanksystemen (Interbase, Oracle, MS SQL, etc.) üblicherweise verwendet werden, hier hat man dann aber zusätzlichen Portierungsaufwand, wenn später mal das Datenbanksystem gewechselt werden sollte... und was, wenn das neue Ziel-Datenbanksystem keine Generatoren unterstützt? :gruebel: Auch Lösungen mit eigenen Implementierungen über Zählertabellen o.ä. sind nicht wirklich so das Gelbe vom Ei... Eine Alternative ist die Verwendung von GUIDs. Diese sind wirklich immer eindeutig (theoretisch zumindest ;-) und lassen sich leicht von der Applikation erzeugen. Jedoch sind diese alphanumerisch und 26 Zeichen lang...

Wie auch immer... egal, für welche Lösung man sich entscheidet, die Primärschlüsselwerte dürfen niemals von der Applikation interpretiert werden (dürfen also keinen Informationsgehalt besitzen) und müssen unveränderlich sein! Ausserdem empfiehlt es sich, grundsätzlich nur Primärschlüssel zu verwenden, die aus einem einzigen Feld bestehen. Dies macht das Leben deutlich einfacher... :wink: Ich nenne meine Primärschlüsselfelder übrigens immer ID und nicht etwa Adr_ID oder Adr_Nr oder sowas in der Art. Auch das hat schon vieles einfacher gemacht...


So... jetzt hör ich mal auf... für meinen ersten Beitrag ist das ja jetzt voll der Roman geworden.... :wink:

[Billa]

Hallo Tharon und alle anderen!

Im Prinzip (...und in der Praxis...) hat Tharon recht. Unserem LOMBI steht aber offensichtlich nur Paradox zur Verfügung. Und wegen des möglichen Ärgers mit Auto-Increment-Feldern sollte man die Zählerei auf ein Mindestmaß beschränken. Die Lösung mit der Zählertabelle ist nicht schön, hat aber im Ernstfall einen Vorteil: Sie darf "kaputt" gehen, da ist ja nix weiter drin und ist leicht nachzubauen. In der wirklich wichtigen Tabelle taucht kein Auto-Increment auf. Mein erster Satz lautete ja auch: "Wenn in der Nummer nichts kodiert ist..." o.ä. Ansonsten wäre der Ansatz in der Tat falsch.

Ich bedauere die Politik von Borland sehr, in der Personal Delphi-Version keine Datenbank-Anbindung zu unterstützen: Mit echten Datenbanken (Firebird u.a.) sind so schöne Dinge möglich und Anfänger könnten von vornherein schlimme Fehler vermeiden!

[LOMBI]

Hallo,

herzlichen Dank für Eure Ausführungen. Besonderer Dank an Tharon für
seine Mühe und umfangreichen Erklärungen.

Gruß
Lombi

[MrSpock]

Hallo Lombi,

da du mich noch einmal auf diesen Thread angesprochen hast, möchte ich dir hier noch einmal helfen. Ich schließe mich den Ausführungen von Tharon an. Du solltest die Prüfung in der BeforePost Methode des TTable Objektes durchführen. Ich glaube es geht dir darum, wie man denn jetzt prüft, ob ein Datensatz mit der eingegebenen AdressenIDNr existiert. Du benötigst für die Überprüfung ein weiteres DB Objekt. Es wäre zwar grundsätzlich möglich zu versuchen, den Datensatz abzuspeichern und auf einen Fehler zu reagieren. Wie gesagt, ich würde die Prüfung aber Vor dem Post also BeforePost durchzuführen. Dazu nimmst du entweder ein zweites TTable Objekt, das auf dieselbe Tabelle zeigt. Dort suchst du den Datensatz mit der AdressenIdNr, die im dem DBEdit Feld steht und zwar entweder über FindKey (sofern die AdressIdNr ein Schlüsselfeld ist) oder aber über Locate. Die beiden Funktionen werden recht gut in der OH beschrieben. Alternativ nutzt du ein TQuery Objekt und speicherst dort die Abfrage (die Tabelle heiße Adressen):

SQL-Code:

SELECT * FROM Adressen WHERE AdressenIdNr = :adr

Durch den Doppelpunkt vor adr wird der Bezeichner adr zu einem Parameter, den du mit ParamByName ansprechen kannst (die Query heiße qryExistsAdr):

Delphi-Quellcode:

// ich nehme einmal an das DBEdit Feld mit der AdressID heißt dbEditAdr
qryExistsAdr.Close;
qryExistsAdr.ParamByName('adr').AsString := dbEditAdr.Text;
qryExistsAdr.Open;
if qryExistsAdr.RecordCount > 0 then
begin
  // Datensatz existiert schon
   // Hier vielleicht eine Fehlermeldung ausgeben
   ABORT; // Speicherversuch abbrechen
end;