und Korruption ist anderen Leuten gegeben
![Wink ;-)](./images/smilies/wink.gif)
Moderator: Moderatoren
Irgendwie meine ich in gelesen zu haben, das Xbase++ automatisch die RECNO() mitspeichert um auf jeden Fall eindeutig zu sein.Ausserdem achte ich noch darauf, dass die Indexdateien relativ eindeutige Sätze haben. Also jetzt nicht eine Adress-dbf auf ORT indizieren und dann gibt´s z.B. hunderte Berliner und nur ein Engelsbrander. Dann erweitere ich den Schlüssel eben, bis er eindeutiger wird.
Code: Alles auswählen
DbSetScope(SCOPE_BOTH,Str(nMeineHundeZahl,10,0))
Jup!Tom hat geschrieben: Oder verstehe ich jetzt was falsch?
Martin, nur zur Beruhigung, das war das erste was ich bitter lernen mußte, dass man einen String bilden mußWichtig!! Nie eine Indexdatei über mehrere numerische Felder aufbauen - in dem Fall immer über Zeichenketten!! Die numerischen Felder würden sonst addiert werden, was ja nicht Sinn der Sache ist!!
dann bin ich ja beruhigt, dass es nicht nur mir so gingManfred hat geschrieben:Martin, nur zur Beruhigung, das war das erste was ich bitter lernen mußte, dass man einen String bilden muß
Ich meine mich erinnern zu können, das es mir damals so erklärt wurde, dass es unbedingt sein muß, wenn ein Schlüssel mehrfach vorkommt. Ich hatte nämlich damals schon ein Problem mit defekten Indexdateien und deshalb nachgefragt. RECNO() alleine sollte man nicht machen.Tom hat geschrieben:Bleibt noch die Frage, wozu das gut sein soll. Kann ich mir, um ehrlich zu sein, im Moment keine Antwort zu vorstellen.
Code: Alles auswählen
INDEX ON Upper(Name) To MyIndex
Code: Alles auswählen
INDEX ON Str(Recno(),10,0)+Upper(Name) To MyIndex
Dreh' das mal um:Tom hat geschrieben:Code: Alles auswählen
INDEX ON Str(Recno(),10,0)+Upper(Name) To MyIndex
Code: Alles auswählen
INDEX ON Upper(Name)+Str(Recno(),10,0) To MyIndex
ich verstehe kein Wort.....Martin Altmann hat geschrieben:
Zum Thema Pack: So was macht man sowieso nichtPhil Ide hat dazu in den Newsgroups recht interessante Tipps gegeben. Aus Gründen der Revisionssicherheit sind mit seiner Vorgehensweise immer zu jeder Zeit jeder Stand der Daten abrufbar.
So ist jederzeit immer alles rekonstruierbar!
- Ein Datensatz wird nie gelöscht - es wird immer in einem speziellen Feld ein Marker gesetzt, der dem Löschen entspricht - ist dieser Marker gesetzt, wird der Datensatz in Listen usw. nicht mehr berücksichtigt.
- Eine Änderung an einem Datensatz wird nie in dem originalen Datensatz durchgeführt - der Datensatz wird vorher immer in einen neuen Datensatz kopiert und dort werden die Änderungen hinterlegt.
- Ein Entlöschen passiert auch durch Kopieren des "gelöschten" Datensatz und entfernen des Löschmarkers in der Kopie.
- Zu all' diesen Aktionen wird auch der Zeitpunkt der Änderung/Löschung und der Account des betreffenden Users, die die Änderung/Löschung vorgenommen hat, abgelegt.
Es geht darum, die strukturelle Integrität der Daten zu erhalten. In einer DBF hat jeder Datensatz nur so lange seine eindeutige Datensatznummer (Recno()), bis die DBF gepackt, sortiert oder umkopiert wird (wenn bei letzterem ein führender Index aktiv ist). Bei Phils Vorschlägen geht es darum, sowohl inhaltlich, als auch referentiell immer nachvollziehen zu können, was mit den Daten geschehen ist, und deshalb kopiert er geänderte Datensätze (der Urdatensatz bleibt erhalten, wird aber ausgeblendet, was man mit SET DELETED ON und einem einfachen Löschen auch erreichen kann). Er packt nie, er kopiert nie um, und er speichert Änderungsinformationen direkt im Datensatz. Das kann unter entsprechenden Bedingungen alles Sinn machen, und es erspart viel Unbill, die mit Reihenfolgen und Referenzen über die Datensatznummer zu tun hat. Aber es ist nicht so, daß man auf diese Art arbeiten muß.ich verstehe kein Wort.....