Und zwar stehe ich vor folgendem Problem. Habe ein Delphi Programm, bei dem es 5 Edit Felder gibt. Der Benutzer füllt nun alle 5 Edit Felder aus und klickt auf einen Button "Speichern".
Nun soll der Inhalt dieser Edit Felder eine Zeile einer Tabelle ergeben. Ich hoffe das ist einigermaßen verständlich. Sobald der Benutzer auf Speichern klickt, soll zum einen der Inhalt der Edit Felder in einer Datei abgespeichert werden und zum anderen soll der Inhalt dieser gesamten Datei im Delphi Programm angezeigt werden (also als Tabellenform).

1) Wie speichere ich den Inhalt der Felder in Tabellenform in einer Datei ab ?

2) Wie lade ich bei jedem Programmstart automatisch diese Datei und wie kann ich sie in Tabellenform anzeigen lassen ?

PS: Von Delphi habe ich wirklich sehr wenig Ahnung. Habe jahrelang in TurboPascal programmiert, aber da war das alles noch nicht so umfangreich wie es heutzutage ist.

Hallo und im Delphi-Forum.

Bitte gebe deinen Posting einen sinvollen Titel. Was sinvoll ist steht in den Richtlinien:

Delphi-Forum Richtlinien hat folgendes geschrieben:

1.1 Beiträge Bitte formuliere den Betreff Deiner Beiträge so, dass andere Mitglieder anhand dieser bereits das eigentliche Thema festmachen können. Beiträge wie etwa "Eine Anfängerfrage" oder "Weiß jemand, wie das geht?" lassen den Leser im Unklaren darüber, was das Thema der Diskussion ist.

Du kannst dein Topic ändern indem du beim Ersten Beitrag auf Edit drückst, es änders und dann wieder Absendest.

Zur Frage:
Was meinst du mit "Tabellenform"? Soll es eine Textdatei (z.B. CSV)werden? Wenn ja, dann geht das im Grunde immer noch so wie unter Turbo Pascal. Stichwörter hierfür sind ASSIGNFILE, RESET, REWITE, APPEND, ReadLn, WriteLn, CLODEFILE, IORESULT.

Für das Laden musst du einfach die entsprechende Rotine im OnCreate Ereignis deines Hauptformulars aufrufen.

Gruß
Klabautermann

Sorry wegen der falschen Betreffzeile (beim nächsten Mal weiß ich es besser).
Zu meinem Problem: Wie das ganze abgespeichert wird (ob als Textdatei oder sonst wie) ist mir völlig egal. Ich hatte gehofft, ihr könnt mir die sinnvollste Möglichkeit nennen. Ne Datenbank wäre ja vielleicht angebracht, hab´ aber keine Ahnung, wie ich damit umgehen muss. Vielleicht kann mal jemand ein kurzes Beispiel geben, wie man eine Tabelle abspeichern und auch wieder laden kann.

Hallo,

dann kommt es drauf an, wieviele Daten du speichern willst.
Eine Datenbank lohnt sich eigentlich erst, wenn du große Datenmengen speichern oder kompexe anfragen machen willst.
Denn bei denen musst du auch immer ein Datenbank Management System mit ausliefern, weis deine Programmpacket oft um mehere MB vergrößern.
Sehr beliebt bei kleinen Datenmenden sind Ini Dateien.
Wie du mit diesen Arbeitest zeigen diese beiden Tutorials (1, 2) und hier kannst du ein Beispiel zu den meiner Meinung nach besseren tMemIniFile runterladen (welches im wesentlichen genauso funktioniert).
Eine modernere aber in deinem Fall warscheinlich überdimensionierte Möglichkeit währe XML.
Auch interessant in dem zusammenhang könnten Typisierte Dateien sein. Die könntest du von Turbo-Pascal kennen. Eine Beispielanwendung dazu findest du ebenfals unter diesem Link.
Zum Darstellen der Informationen würde ich dir dann die Komponente tStringGrid oder tListView empfehlen.

Gruß
Klabautermann

PS: Ich verschiebe das hier erst mal in Dateizugriff.

Das ist doch mal was Konkretes. Danke erstmal dafür.

An eine ini-Datei habe ich wegen der einfachen handhabung auch schon gedacht, wusste allerdings nicht, ob die nicht nachher zu groß ist.

Die Tabelle besteht aus 200 Zeilen zu je 5 oder 6 Einträgen. Wäre da nicht ´ne ini-Datei zu groß ? Hab´ keine Ahnung, wie groß eine 1000 Zeilen lange ini-Datei ist.

Hallo,

alos ich würde dir zu tMemIniFile Raten (siehe beispiel) dmait kannst du auch Große Dateien erstellen (tIniFile ist auf 64kByte begrenzt). Diese Speichert aber nciht automatisch bei jeder änderung, sondern erst wenn du einen Befehl dazu gibst, somit ist sie schneller als tIniFile, du musst nur selber drauf achten irgendwann (spätestens beim beenden des Programs) die Daten zu speichern.

Wie groß die Datei wird ist natürlich eine Frage der zeilenlänge. Jeder Buchstabe ist ein Byte. 1024 Buchstaben = 1 kByte.
Ich habe grade mit dem tMemIniFile Beispielprogramm eine Dateim mit ca. 1.500 Zeilen erzeugt, das hat keine 2 Sekunden gedauert und die Datei ist 10,4 kByte groß.
Wenn du keine Romane in deinen 1000 Zeilen stehen hast sollte das mit der INI-Datei gehen.

Für Datenbanken sind die von dir angegebenen Datenmengen eigentlich nicht der rede wert. Will sagen, die währen ziemlich gelangweilt .

Gruß
Klabautermann

Hi,
was is denn mit na StringList ?
Ich hab die grad auch das erste mal benutzt und muss echt sagen das das damit auch recht leicht geht

MfG BungeeBug

Hallo,

BungeeBug hat folgendes geschrieben:

was is denn mit na StringList ?

das ist fast das selbe. Nur das du die Einteilungen (sektionen) ncit hast und die Komponente dir auch das umformatiernen von Zahlen und Datumswerten nicht abnimmt. Mnn erhällt also eine "unformatierte" Textdatei.

Es ist aber eine Variante, die du Jas DA in deine überlegungen aufnehmen solltest.

Gruß
Klabautermann

Ich werde das Ganze jetzt mal mit der ini-Datei versuchen. Denke auch, dass ich keine Probleme damit haben werde. Ansonsten weiß ich ja jetzt, wo ich Hilfe finde.

Hallo,
was spricht eigentlich gegen Paradox-Tabellen?

Damit kauft man sich einige Vorteile, wenn es irgendwann an die Datenausgabe auf Papier geht. (Quickreport).

Kalli

Hallo,

Kalli hat folgendes geschrieben:

was spricht eigentlich gegen Paradox-Tabellen?

die BDE. Damit muss Jas DA dann ca. 6,5 MB mehr Daten ausliefern wenn er sein Programm mal veröffentlichen will.

Gruß
Klabautermann

Hi,

da hast Du natürlich recht. Aber, was sind in der heutigen Zeit 6,5 MB? Erstellt man das Setup mit 'Express für Delphi' kann man alle Einstellungen vornehmen.
In vielen Fällen ist die BDE bereits auf dem Zielrechner vorhanden, so dass nur die ALIAS-Einträge ergänzt werden.
Aus eigener Erfahrung weiss ich, dass mit dem Programmieren die Anforderungen an die Datenquellen steigen. Es sei denn, dass einen eine eventuelle Datenredundans nicht weiter stört.
Es sollte auch nur ein Tipp sein, da ich mit diesen Tabellen fast alles löse.

Bis dann dann
Kalli

Hallo,

der Tipp ist auch durchaus willkommen. Auch meine Antwort sollte ein solcher sein. Auch wenn diese direckt auf die Frage von dir folgte ist sie als hinweis für Jas DA gemeint. Denn es geht hier ja dadrum das er aus den Informationen die wir alle geben die für ihn günstigste Antwort raussucht.

Von dem BDE/Paradox gespann würde ich auch aus persölicher erfahrung abraten. Da bin ich ein gebranntes Kind. Ich würde da zu anderen Datenbanken raten. Aber ich denke für sein Problem ist die eine wie die andere (inkl. Paradox) überdimensioniert.

Gruß
Klabautermann

...Von dem BDE/Paradox gespann würde ich auch aus persölicher erfahrung abraten....

Warum (ausser BDE) ? Habe bisher noch keinen Schaden erlitten... aber vorbeugen ist besser als nach hinten fallen...

Hi,
es ist schon etwas paradox mit Paradox.

Eigentlich weiß jeder, dass Paradox nicht geeignet ist, aber keiner weiß genau warum. Es gibt halt einige Funktionen, bei denen man mit Vorsicht ran muß (z.B. löschen mehrerer Datensätze in verknüpften Tabellen). Ich habe momentan 5 Projekte am Laufen, die voll auf Paradoc-Tabellen zurückgreifen. Ein Versuch mit Access ist schon in der Planung gescheitert (dies liegt wohl daran, dass ich seit fast 8 Jaheren mit Paradox arbeite). Die Nachteile mit den einzelnen Dateien finde ich nicht so tragisch und wie ich schon gesagt habe, gibt es viele Programme, die die BDE mitbringen.

Bei den Programmen handelt es sich um ein komplettes Provisionssystem, bei dem Tabellen mit über 100.000 Einträge kein Problem bereiten. Ein Teil der Programme läuft im Netz und es werden von 5-6 Arbeitsplätzen auf die Daten zugegriffen.

Das einzige Problem was auftaucht ist ein Angebotsprogramm. Bei jedem Update überschreibt es mir die BDE-Einstellungen. Hiergegen hab ich aber ein Programm geschrieben, was dies dann wieder berichtigt.

Fazit: Wegen der vielen negativer Berichte habe ich zwar ein ungutes Gefühl, aber eine Umstellung nur aus diesem Grund werde ich wohl nicht vornehmen. (Mit allen Dienstprogrammen wären es ca. 12 Programme und an die 60 Tabellen sowie unzählige Quickreports).

Das ganze sind so meine Gedanken und Erfahrungen zu Paradox.
Würde ich von Vorne beginnen, hätte ich auch die Qual der Wahl.

Kalli

das Problem mit den BDE- Einstellungen hatte ich auch mal unter D3. Hab das damals mit etwas direkterer Programmierung (zusätzliche Aliasangaben im Prg. usw.) wegbekommen. Sonst hatte ich nie Ärger. Also lasse ich alles wie es ist, wenn es nichts konkreteres gibt....