AEWWSLite FEHLER Index doppelt oder leer: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „ Gesetz: Ein Index darf niemals doppelt sein! Das Feld INDEX muss eindeutig sein - ein Wert darf jeweils nur einmalig vorkommen. Das Indexfeld in der Datenbank darf auch niemals leere sein. Falls eine dieser Konstellationen auftritt wurde die Datenbank zerstört und eine sichere Nutzung nicht mehr möglich. Eine solche Datenbank dürfen Sie nicht mehr verwenden. Steigen Sie unbedingt auf eine Sicherung Ihre Datenbank um, die diesen Fehler nicht aufweist!…“) |
KKeine Bearbeitungszusammenfassung |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Gesetz: Ein Index darf niemals doppelt sein! Das Feld | Gesetz: Ein Index in der Artikeltabelle darf niemals doppelt sein! Das Feld IDX muss eindeutig sein - ein Wert darf jeweils nur einmalig vorkommen. Das Indexfeld in der Datenbank darf auch niemals leere sein. Falls eine dieser Konstellationen auftritt wurde die Datenbank zerstört und eine sichere Nutzung nicht mehr möglich. Eine solche Datenbank dürfen Sie nicht mehr verwenden. Steigen Sie unbedingt auf eine Sicherung Ihre Datenbank um, die diesen Fehler nicht aufweist! | ||
Bei 2.15 Versionen: Der Datentyp ist auf INT (Integer) definiert und kann Werte bis zu 2.147.483.647 annehmen. Der Index ist ein Lebenszähler, d.h es wird alles gezählt, was einmal als Datensatz verwendet wurde. Dieses schließt auch gelöschte Datensätze mit ein. | Bei 2.15 Versionen: Der Datentyp ist auf INT (Integer) definiert und kann Werte bis zu 2.147.483.647 annehmen. Der Index ist ein Lebenszähler, d.h es wird alles gezählt, was einmal als Datensatz verwendet wurde. Dieses schließt auch gelöschte Datensätze mit ein. | ||
Zeile 9: | Zeile 9: | ||
Wenn keine Sicherung vorliegt (So sollten Sie nicht arbeiten - aber für den Fall, dass...): Die Buchungen im Journal sind verloren. Die Datenbank können Sie unter Umständen noch retten. Datenbank als XLS CSV Datei exportieren und dabei NICHT das Feld INDEX exportieren. Dann neue Datenbank öffnen und XLS CSV Datei importieren. Das Programm wird einen neuen Index vergeben und Sie haben zumindest Ihre Daten gerettet. Evtl müssen Sie doppelte Datensätze dann löschen, aber wenn der Index eindeutig ist, können Sie zumindest wieder mit dem Programm arbeiten! Falls die Bestände nicht stimmen, müssen Sie evtl mit einer Anfangsinventur beginnen. (Der Tipp gilt für XML UND SQL Datenbanken - wobei Sie bei SQL natürlich serverseitig die ganze Tabellen löschen müssen.) | Wenn keine Sicherung vorliegt (So sollten Sie nicht arbeiten - aber für den Fall, dass...): Die Buchungen im Journal sind verloren. Die Datenbank können Sie unter Umständen noch retten. Datenbank als XLS CSV Datei exportieren und dabei NICHT das Feld INDEX exportieren. Dann neue Datenbank öffnen und XLS CSV Datei importieren. Das Programm wird einen neuen Index vergeben und Sie haben zumindest Ihre Daten gerettet. Evtl müssen Sie doppelte Datensätze dann löschen, aber wenn der Index eindeutig ist, können Sie zumindest wieder mit dem Programm arbeiten! Falls die Bestände nicht stimmen, müssen Sie evtl mit einer Anfangsinventur beginnen. (Der Tipp gilt für XML UND SQL Datenbanken - wobei Sie bei SQL natürlich serverseitig die ganze Tabellen löschen müssen.) | ||
Hinweis: Die o.a. Angaben zum Index beziehen sich auf die Artikeldatenbank. Innerhalb der Logdatei kann der Index doppelt vorkommen. Daher darf er bei SQL NICHT als Primärschlüssel definiert werden! Beisp: 2 Benutzer erfassen gleichzeitig Buchungen ohne vorher jeweils einen Update der SQL Tabelle durchzuführen. Dann ist es möglich, dass in der Logdatei ein gleicher Index verwendet wird, ohne dass später Probleme zu erwarten sind. Die in der Artikeltabelle verwendeten Indizes müssen jedoch abweichend sein! |
Aktuelle Version vom 14. November 2023, 18:29 Uhr
Gesetz: Ein Index in der Artikeltabelle darf niemals doppelt sein! Das Feld IDX muss eindeutig sein - ein Wert darf jeweils nur einmalig vorkommen. Das Indexfeld in der Datenbank darf auch niemals leere sein. Falls eine dieser Konstellationen auftritt wurde die Datenbank zerstört und eine sichere Nutzung nicht mehr möglich. Eine solche Datenbank dürfen Sie nicht mehr verwenden. Steigen Sie unbedingt auf eine Sicherung Ihre Datenbank um, die diesen Fehler nicht aufweist!
Bei 2.15 Versionen: Der Datentyp ist auf INT (Integer) definiert und kann Werte bis zu 2.147.483.647 annehmen. Der Index ist ein Lebenszähler, d.h es wird alles gezählt, was einmal als Datensatz verwendet wurde. Dieses schließt auch gelöschte Datensätze mit ein.
Bei SQL: Das Feld muss auf INT gesetzt werden und kann ebenfalls Werte bis zu 2.147.483.647 annehmen. (Quelle: Microsoft MSDN) Wichtig: In SQL sollte das Feld INDEX auf PRIMÄRSCHLÜSSEL gesetzt sein. So wird bereits der SQL Server verhindern, dass doppelte Index existieren und selbst wenn Ihre Datenbank nachträglich via SQL kompromittiert (z.B. durch einen Hack beschädigt) wird, meldet sich der SQL Server sofort mit einer Fehlermeldung!
Um Index zu testen: Neuen Datensatz erfassen. Es sollte der nächste freie Indexwert vergeben werden. Anschließend die Datenbank nach Index sortieren - wenn Sie doppelte Index haben ist die Datenbank defekt und kann nicht mehr verwendet werden. Siehe oben.
Wenn keine Sicherung vorliegt (So sollten Sie nicht arbeiten - aber für den Fall, dass...): Die Buchungen im Journal sind verloren. Die Datenbank können Sie unter Umständen noch retten. Datenbank als XLS CSV Datei exportieren und dabei NICHT das Feld INDEX exportieren. Dann neue Datenbank öffnen und XLS CSV Datei importieren. Das Programm wird einen neuen Index vergeben und Sie haben zumindest Ihre Daten gerettet. Evtl müssen Sie doppelte Datensätze dann löschen, aber wenn der Index eindeutig ist, können Sie zumindest wieder mit dem Programm arbeiten! Falls die Bestände nicht stimmen, müssen Sie evtl mit einer Anfangsinventur beginnen. (Der Tipp gilt für XML UND SQL Datenbanken - wobei Sie bei SQL natürlich serverseitig die ganze Tabellen löschen müssen.)
Hinweis: Die o.a. Angaben zum Index beziehen sich auf die Artikeldatenbank. Innerhalb der Logdatei kann der Index doppelt vorkommen. Daher darf er bei SQL NICHT als Primärschlüssel definiert werden! Beisp: 2 Benutzer erfassen gleichzeitig Buchungen ohne vorher jeweils einen Update der SQL Tabelle durchzuführen. Dann ist es möglich, dass in der Logdatei ein gleicher Index verwendet wird, ohne dass später Probleme zu erwarten sind. Die in der Artikeltabelle verwendeten Indizes müssen jedoch abweichend sein!