Hallo! Wenn z.B. ein Datensatz entfernt wird, weil derjenige nicht mehr dem Verein angehört, so schreibt das System automatisch in der Tabelle beim nächsten eingegebenen Datensatz die ID fort, es ist dann aber tatsächlich einer weniger in meinem Beispiel. Wie kann ich das neu organisieren. Mit "Sortieren" hatte ich keinen Erfolg. Für Hilfe wäre ich dankbar. Gruss Schwebebahn
Ich habe die SQL Variante so eingegeben wie oben aber nach RESTART WITH 1 Das System hat die Angelegenheit erfolgreich durchgeführt aber es kam dann die Meldung 0 rows upgedated
Natürlich hast Du kein Update auf irgendeine Zeile ausgeführt. Du hast den Primärschlüssel lediglich auf '1' zurückgesetzt. Da sind doch keine Daten in irgendeiner Zeile geändert worden.
Danke für eure Hilfe, Damit das jetzt einfacher für den Benutzer wird, habe ich die ID in der Tabelle nicht sichtbar gemacht, der Benutzer kann die Menge der Mitglieder in den Abfragen und in den Berichten sehen. Danke nochmals.
Die beste Methode: Du ignorierst die "ID". Ich habe so ein Spielchen mit einer Bibliotheksdatenbank einmal gehabt: Da wollten doch die Nutzerinnen, dass die "ID" mit der Anzahl der Datensätze so weit wie möglich übereinstimmte. Ich habe dann eine Funktion geschrieben, die vor dem Einfügen neuer Datensätze erst einmal erforschte, welches denn die erste freie "ID" sei, weil eben ausgemusterte Medien aus der Datenbank gelöscht wurden. Das kostet mich Zeit zum Entwickeln, dass kostet den Rechner Zeit zum Nachsehen - und letztlich stimmt die maximale "ID" trotzdem nur in den seltensten Fällen.
Folgender SQL-Befehl setzt die "ID" auf einen neuen Startwert, sofern Du die HSQLDB betreibst:
ALTER TABLE "Tabellenname"
ALTER COLUMN "Feldname" RESTART WITH <neuer_Feldwert>;
Das nutze ich, wenn ich eine Datenbank durchgetestet habe und jetzt die Daten gelöscht habe. Dann state ich anschließend für die ernsthafte Eingabe eben alles wieder bei '1'. Der Befehl für die interne Firebird-Datenbank ist da etwas umständlicher, das Du für diese Datenbank erst einmal den Generator rausbekommen musst, der den Wert hochzählt.
Folgendes Verfahren lässt statt der ID zu, dass Du mit einer laufenden Nummer arbeitest, die Dir genau die Zahl Deiner Datensätze anzeigt:
SELECT "a".*, (SELECT COUNT("ID") FROM "Tabellenname" WHERE "ID" <= "a"."ID") AS "lfd.Nr"
FROM "Tabellenname" AS "a"
Mit dieser korrelierenden Unterabfrage hast Du eine Spalte "lfd.Nr", die bei 1 beginnt und beim letzten Datensatz genau die Zahl der Datensätze hat. Die Abfrage kannst Du auch in Formularen zu Eingaben nutzen - nur ist das Feld "lfd.Nr" nicht bearbeitbar.
Gefragt: 2020-05-12 16:03:38 +0100
Angesehen: 85 Mal
Aktualisiert: May 12 '20
Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Dein Vorhaben vermag die Integrität Deiner Datenbank völlig korrumpieren.
Aber nur, wenn die Beziehungen nicht in Extras > Beziehungen definiert sind. Ansonsten blockiert die Definition oder setzt automatisch geänderte Primärschlüssel an anderer Stelle. Unter MySQL und MyISAM-Tabellen war das früher ein Problem.
Allerdings würde ich die Schlüsselfelder auch in Ruhe liegen lassen. Alte Mitglieder werden nicht gelöscht sondern mit einem Vermerk "gekündigt" o.ä. versehen, solange noch andere Datensätze zu den Mitgliedern in der Datenbank existieren, sie also z.B. noch einen Schlüssel für das Vereinsheim haben.
Ich wollte nur auf potentielle Risiken hinweisen. Das ganze Design ist ja erst mal nicht bekannt