Überprüfen von ID-Nummern

[LOMBI]

Hallo,

auf dem Formular ist u.a eine DBEdit für die Adressen-Id-Nr
vorgesehen. Diese Id-Nr. kann aus Zahlen und/oder Buchstaben
bestehen. Bei der Eingabe soll geprüft werden, ob die Id-Nr
schon vergeben ist und wenn ja, eine entsprechende Meldung
darauf hinweisen, dass eine neue ID-Nr. gewählt werden muß.

Ich arbeite mit Paradox7-Tabellen und Delphi3-Prof. Wer kann
mir bitte als Anfänger helfen? Besten Dank vorab!

Grüße

[Fourcorner]

Solly,
wie speicherst du die anderen Einträge?

[LOMBI]

Hallo Fourcorner,

danke für Deine Meldung!

Die anderen Einträge (Name, Vorname usw.) werden in der gleichen Tabelle gespeichert. Der Zähler +/- für die ID nützt nichts, weil damit
keine individuellen IDs möglich sind.

Viele Grüße
Lombi

[kiar]

hallo lombi,

die id jedes mal von hand einzugeben, sehe ich keinen sinn. diese auch noch mit und /oder Bucstaben zu machen
macht deine suche langsamer, da jedes mal zeichen für zeichen mit dem Feld in der db verglichen werden muss.

ich würde so viel wie mögich die tabelle machen lassen, und wenn paradox dieses autoincrement anbietet, solltest du es auch nutzen.

wenn du was individuelles haben willst, mache es über zusammengesetzte Indexe, die gingen glaub ich in paradox.

raik

[LOMBI]

Hi raik,

danke für die Antwort. Es gibt doch sehr viele Anwendungsprogramme,
in denen alphanumerische Werte als Id-Nr. zugelassen sind?

Gruß
Lombi

[Billa]

Hallo,

Wenn in der gewünschten Nummer nix codiert ist: wie wäre es mit einer simplen Umrechnung einer laufenden Nummer in einen hexadezimalen Wert ( ...oder eine andere Zahlenbasis... ). Will man den Zähler nicht selbst verwalten genügt eine ansonsten leere Hilfstabelle, die nur ein Feld (das Autoincrement-Feld) enthält. Neuen Satz anlegen, Nummer lesen, Satz löschen... Die Nummer kann dann ja wie oben erwähnt umgerechnet werden...Algorithmen dazu finden sich in der Code-Library.

[LOMBI]

Hallo Billa,

danke für Deinen Vorschlag. Scheint für einen Programmier-Anfänger
etwas kompliziert zu sein. Für die Adressen-ID erstelle ich also eine neue Par.7-Tabelle mit nur einem Feld (vom Typ A?) und verbinde
diese Tabelle mit meinem bisherigen Formular. Wie wird aus diesem
Feld dann das Autoincrement-Feld?

Gruß
Lombi

[Hansa]

Ich glaube, ihr verwechselt hier die einzugebende Adress-Nr. mit dem Autoincrement-Wert. Das "Auto" steht für "automatisch" und das increment für Erhöhung. Da gibt es nichts von Hand alphanumerisch einzugeben. Das ist nur eine interne Nr., an die der User niemals rankommen soll und darf.

Die Adress-Nr., die der User eingeben kann, die kann natürlich auch alphanumerisch sein. Du mußt eben am besten im Onexit des Edits überprüfen, ob es diese nr. schon gibt.

[fiasko]

Hallo,

Zitat:

Zitat von kiar

ich würde so viel wie mögich die tabelle machen lassen, und wenn paradox dieses autoincrement anbietet, solltest du es auch nutzen.

wenn du Refenzen auf diese ID's machen willst (davon gehe ich mal aus, sonst macht es ja wenig sinn) würde ich davon die Finger nehmen. Ich habe schlechte Erfahrungen mit Paradox und Auto-Inkrement-Feldern gemacht... wenn es da mal den Index einer Tabelle zerschossen hatte ändern sich u.U. die Werte dieser Felder... und dann stimmt das vorn und hinten nicht mehr.

[LOMBI]

Hallo,

danke für das Interesse. Kann mir bitte jemand noch erklären, wie
das geht, um mit onexit die alphanumerischen Einträge im Edit zu überprüfen?

Gruß
Lombi

[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;