Arbeiten mit Records

[Erutan]

Hallo,

wie man typisierte Daten grundsätzlich anlegt und verwaltet, habe ich mittlerweile so weit kappiert. Es gibt ja reichlich Anleitungen dazu Was mir aber dabei fehlt ist eine einfache Möglichkeit des Zugriffs auf bestimmte Datensätze.

Bei allen Beispielen kann man jeweils nur neue Datensätze anlegen, alte löschen, jeweils um einen Datensatz nach vorn oder zurück sprigen sowie zum ersten und zum letzten Datensatz springen.

Doch was, wenn ich geziet einen Datensatz aus einem solchen Record auswählen will? Wie würde man so etwas am elegantesten lösen? Über eine Suchmaske vielleicht, die z.B. nach Nachnamen oder anderen Bestandteilen eines Daensatzes sucht und dann als Ergebnis den kompletten Datesatz liefert? Oder über eine Liste in der von jedem Datensatz z.B. der Nachname aufgelistet ist und sich mit Click auswählen läßt?

Wie würde sich eine solche Liste umsetzen lassen?

Also ganz konkret:

Welche Komponente verwende ich hierfür am besten? Sicher keine Memo. Eine Kombibox vielleicht?
Wie ich dieser Komponente beim Anlegen eines neuen Datensatzes einen entsprechenden Bezeichner hinzufüge kriege ich sicher raus - wie das umgekehrt funktioniert, wie bei Cklic auf den Bezeichner dann der gesamte Datensatz aush´gewählt wird, sicherlich nicht.

Das (für mich) größte Problem dabei: Wenn ich nur um jeweils einen Datesatz nach vorn oder hinten springe weiß ich jederzeit wo ich bin. Wenn ich die Datensätze aber nicht der reihenfolgen entsprechend auswähle...wie behalte ich dann den Überblick?

[Sherlock]

Also erstmal: Ein Datensatz ist ein Record (zufällig auch in der DE-EN Übersetzung).
Eine Menge von Records (Datensätze) hältst Du ja in irgendeiner mehr oder weniger geeigneten Struktur (zB Array oder Liste).
Dann wird es für mich leider etwas konfus. Was willst Du machen? Einen Datensatz anzeigen? Einen Suchdialog aufbauen?
Für eine Liste eignet sich mMn eine TListBox ganz hervorragend. Um einen neuen Satz anzulegen brauchst Du sicher einen Eingabedialog, der alle userfüllbaren Felder editierbar anzeigt.

Schließlich musst Du Dir nicht so viele Gedanken über "Überblick behalten" machen. Du willst etwas bestimmtes suchen, dann tu das einfach. Wo was ist, ist dann zunächst zweitrangig. Ich gehe davon aus, daß Du Anfänger bist, also ist es recht gut erstmal einfach loszulegen, bevor Du Dir überlegst daß die Records in einer Baumstruktur vielleicht ganz gut aufgehoben sein könnten, um eine Suche nach bestimmten Feldern effizienter zu gestalten.

Sherlock

[stahli]

Dafür gibt es verschiedene Lösungen. Je nachdem, was Du genau machen willst bzw. wie umfangreich und wartbar Dein Projekt sein soll.

Grundsätztlich sind Datenbanken dafür überlegenswert. Die DB-Controls kümmern sich dann um die Beziehung der angezeigten und gespeicherten Daten(sätze).

Wenn Du es von Hand machen willst, wirst Du eine ID einführen müssen. Dann kennt jedes Control die ID "seiner" Daten und kann den korrekten Record abfragen.

Ich würde aber dann eher Objekte verwenden und diese in Listen speichern. Das ist vom Handling her (m.E.) etwas angenehmer.

In aktuellen Delphiversionen gibt es unterschiedliche Ansätze von "DataBinding", die die den Austausch von Datanmengen mit den GUI-Controls automatisieren sollen. So richtig ausgereift ist das aber noch nicht und mit Delphi7 ist so etwas auch rel. schwer lösbar.

Mein Tipp: Prüfe mal die Verwendung einer Datenbank.
Oder schreib nochmal genauer, was Du genau machen willst und wie Du Deine Daten speicherst.

[DeddyH]

Wenn ich mal ausnahmsweise mit Records arbeite, komme ich im Normalfall ohne IDs aus: Records in eine Liste packen und dann über Indizes ansprechen. Die Pointer in der Liste sind ja eindeutig, da braucht es kein spezielles Feld im Record. Aber so etwas sollte man sich eben im Vorfeld überlegen, die Darstellung ist ja erst einmal zweitrangig.

[p80286]

Naja es kommt wie immer auf die Daten an. Wenn man z.b. Adressen hat und der Zugriff über den Familiennamen geht muß man entweder mehrere Datensätze als ergebnis akzeptieren, oder eben ein weiteres Feld (ID,Vorname....) zur Identifikation heranziehen.

Und da es hier jetzt ums Lernen geht, würde ich nicht mit einer DB arbeiten. Für ernsthafte Projekte wäre sie allerdings zu bevorzugen.

Gruß
K-H

[DeddyH]

Ob ich nun eine ID habe oder einen Array- bzw. Listenindex, welchen Unterschied macht das?

[p80286]

Es geht ja um die Identifikation des Datensatzes also den Inhalt. Wenn Du über einen Arrayindex zugreifst erwischst Du ja irgendwelche Daten die sich an dieser Position befinden.
Ich gehe jetzt mal davon aus, daß die gelesenen Daten nicht immer an der gleichen Position in Liste/Array auftauchen.
Wenn Du allerdings über einen Index auf die Daten zugreifst, dan mußt Du natürlich über den Array/Listen-Index kommen.

Gruß
K-H

[musicman56]

Zitat von Erutan:

...Das (für mich) größte Problem dabei: Wenn ich nur um jeweils einen Datesatz nach vorn oder hinten springe weiß ich jederzeit wo ich bin. Wenn ich die Datensätze aber nicht der reihenfolgen entsprechend auswähle...wie behalte ich dann den Überblick?

Noch zu DOS-Zeiten, als es neben dBase, Clipper und Cobol nicht viel gab, habe ich mal sowas gebastelt: Eine typisierte Datei mit separaten Index-Dateien. Macht allerdings nur Sinn, wenn relativ oft und viel gesucht wird, aber wenig hinzugefügt/gelöscht wird, weil bei jedem Append oder Delete alle Indexdateien neu aufgebaut werden müssen.

Du gehst deine Datendatei sequenziell durch und erstellst eine sortierte Liste mit dem jeweiligen Suchbegriff (wenn es ein string ist natürlich uppercase) und der Satznummer. Das Ergebnis (Feldinhalt und Record-Nummer) schreibst du dann in die Index-Datei.

Für die Anzeige navigierst du statt in der Datendatei in der Index-Datei und suchst für die Anzeige die jeweilige Record-Nummer in der Datendatei.

Zum Suchen reicht dann ein einfaches TEdit für die Eingabe des Suchbegriffes. Mit einem einfachen "<" oder ">" - Vergleich weißt du, ob du in der Indexdatei vorwärts oder rückwärts gehen musst.

[Furtbichler]

Zitat von DeddyH:

Ob ich nun eine ID habe oder einen Array- bzw. Listenindex, welchen Unterschied macht das?

Das merkst Du dann, wenn Du etwas aus der Liste entfernst oder einfügst. Der Instanzenzeiger ist nicht schlecht, aber beim Kopieren eines Records, z.B. zum Editieren mit der Möglichkeit, die Änderungen zu verwerfen, nicht mehr zu gebrauchen.

Davon abgesehen, das es einfach keine gute Idee ist, mit Records und Listen derartige Operationen durchzuführen, sollten Records einen Identifikator besitzen, so wie eigentlich jede Entität.

Aber davon abgesehen: Records? Nee.

[sx2008]

Kleine Entwicklungsgeschichte von dBase...

Am Anfang gab es nur Records mit fester Satzlänge (in Pascal/Delphi als typisierte Datei bekannt).
Dann tauchte aber schon das erste Problem auf:
wie kann man einen Datensatz mitten in der Datei löschen ohne dass man unter Unständen viele Megabytes in der Datei verschieben muss?
Die Lösung ist, dass das 1 Byte im Record den Löschstatus angibt.
' ' bedeutet Datensatz gültig
'*' bedeutet Datensatz gelöscht bzw. als gelöscht markiert

Irgendwann muss man die als gelöscht markierten Datensätze wieder entfernen.
Daher braucht man ein Tool, dass die Recordlänge und die Datei kennt und dann nur die nicht-gelöschten Records in eine neue Datei kopiert.
Das Problem dabei ist falls die Recordlänge nicht stimmt ist das Ergebnis nur noch Datenmüll.

Der nächste Entwicklungsschritt war also dass die Datei einen Header bekommt in dem die Recordlänge vermerkt ist.
Im Header wird zusätzlich aber noch eine Feldliste geführt.
Für jedes Feld wird der Feldname (max 10 Zeichen), Feldlänge, Datentyp (C=Character, N=Numerisch, D=Datum, L=Logisch/Boolean) und ggf. Anzahl der Nachkommastellen gespeichert.
Im Header stehen noch weitere Infos wie z.B. die dBase-Version, Datum der letzten Änderung, Anzahl Datensätze, Zeichensatz, ...
http://www.dbase.com/Knowledgebase/INT/db7_file_fmt.htm

Die Datenfelder werden aus der Software auch nicht mehr über ihre feste Position im Record sondern über ihren Feldnamen angesprochen.
Diese Technik war vor vielen Jahren revolutionär und hat dBase zur Erfolgsgeschichte gemacht.
Durch die Feldbeschreibung im Header konnte man z.B. neue Felder hinzufügen oder die Reihenfolge ändern ohne dass die Anwendungen damit ein Problem bekommen.

Das ist aber noch nicht alles.
Um Datensätze schnell aufzufinden wurde parallel zur dBase Datendatei noch eine oder mehrere Indexdateien geführt.
Ausserdem gab es noch eine weitere Datei in der Felder mit variabler Länge (Memo Felder) gespeichert wurden.

Was ich hier beschrieben habe ist Stand der Technik im Jahr 1985 und die war den alten typisierten Dateien weit überlegen.