Kauf- und Kontenverwaltung - Datenbank notwendig?

[Delphi.Narium]

Bei der Aufgabenstellung: Datenbank

Das alles selbst zu verwalten wird schnell sehr aufwändig.

SQLite, FireBird (embedded), Access.

[Asura]

Zitat von Delphi.Narium:

Bei der Aufgabenstellung: Datenbank

Das alles selbst zu verwalten wird schnell sehr aufwändig.

SQLite, FireBird (embedded), Access.

Ich habe mal bisschen auf Google geschaut, bezüglich Tutorials für die Verbindng Access Datenbank, jedoch leider nichts brauchbares gefunden.
Gibt es eventuell eine Linksammlung oder etwas vergleichbares, was mir das einarbeiten in diese Thematik ermöglicht?

[Delphi.Narium]

Auf Access kann man mit den ADO-Komponenten zugreifen, bzw. allen Datenbankkomponenten, die u. a. ODBC ... unterstützen.

Ansonsten funktioniert der Zugriff, wie bei allen Datenbanken auch, da gibt es programmiertechnisch eigentlich keine Unterschiede.

Über die ODBC-Verwaltung müsste man eigentlich bei Hinzufügen Mircosoft-Access auswählen können. Dort vergibt man den Namen der Datenbankverbindung und kann auch sofort eine neue Datenbank erstellen lassen, man bekommt dann eine leere Datenbankdatei.

Die benötigten Tabellen kann man per SQL erstellen.

Die Datenbankdatei wählt man dann in der Datenbankverbindung der Datenbankkomponente(n) in Delphi aus.

Ein bestimmtes Tutorial kenne ich da jetzt nicht, aber hier solltest Du so allerlei finden können:
tutorial delphi source Access
tutorial delphi sql

[Timelord]

Zitat von Delphi.Narium:

SQLite, FireBird (embedded), Access.

Ich habe bisher gute Erfahrungen mit SQLite gemacht (zwar nicht direkt von Delphi/Pascal aus, aber das sollte übertragbar sein...).
Vorteil an diesen "direkt zugegriffenen" Datenbankfiles gegenüber individualisiertn Textdateien ist eindeutig die leichtere Interoperabilität/Migrationsfähigkeit, mit einer "großen" relationalen Datenbank (z.B. MariaDB). Ich schließe mich gerne meinen Vorrednern an, wenn gesagt wird, dass man auch mehr Funktionalität bekommt: Bei einem Textformat lernt man mit Sicherheit wie soetwas funktioniert usw, aber bei Datenbanken/Datenbankdateien bekommt man den zusätzlichen Aufwand (Suche, Filter, etc) einfach freihaus geschenkt dazu.

[Rollo62]

Ich würde das zwar auch mit richtiger db machen,
Aber warum nicht Beides ?

Mit TFdMemTable eine inmemory db nutzen und mit save und loadfile als textdatei speichern.

Rollo

[HolgerX]

Hmm..

Ich hab mal (Quick and Dirty) ein paar Tools gebastelt, welche ich ohne Datenbank, jedoch dennoch mit Datenmengen benutzt habe.

Da hier die Datenmengen gering waren (so ca. 20-100 Datensätze) und zumeist Statisch, konnte ich auf eine Datenbank als solches verzichten.

Stichwort ClientDataSet (OK, habe hier das TADODataset verwendet).

Bei Programmstart habe ich die Daten aus einem File in das Dataset geladen und bei Programmende oder nach Veränderungen an der Datenmenge einfach wieder in das gleiche File weggespeichert.

Beim Test als XML und später dann Binär.
Somit konnte diese Datenmenge nicht mehr so einfach ohne mein Tool bearbeitet werden

Wenn nun die Daten so umfangreich werden, dass diese nicht mehr praktikabel in ein File weggespeichert werden können, dann kann ich das Dataset einfach in z.B. eine AccessDB oder SQL-Server packen und nehme statt TADODataSet einfach nen TADOQuery zum Holen der Datenmenge.

Das weitere Tool bleibt dann identisch.