(Access-)Datenbank-Zugriff ohne Engine

[Marphy]

Hallo zusammen,
ich bin vor einigen Monaten von Visual Basic auf Delphi gewechselt (die Gründe könnt ihr euch sicher denken ;-) ), bin also ziemlich neu in der Delphi-Welt und mit Datenbanken habe ich auch noch nicht sonderlich viel gemacht.
Nun aber zum Thema:

Mein Programm soll auf eine Datenbank zugreifen, die in einer Datei mehrere Tabellen bündelt. Dazu bietet sich die Access-Datenbank eigentlich an? Nun soll das ganze auch möglichst ohne Engine laufen (sonst wird das Setup zu groß). Mit DAO soll das funktionieren, ist aber recht unkomfortabel.

Wisst ihr weiter? :stupid:

Danke für eure Hilfe schon im Voraus,
Marco

[shmia]

Zitat:

Zitat von Marphy

Mein Programm soll auf eine Datenbank zugreifen, die in einer Datei mehrere Tabellen bündelt. Dazu bietet sich die Access-Datenbank eigentlich an? Nun soll das ganze auch möglichst ohne Engine laufen (sonst wird das Setup zu groß). Mit DAO soll das funktionieren, ist aber recht unkomfortabel

Ohne die Jet-Engine ist sinnvoller kein Zugriff auf Access Datenbanken möglich.
Ein grosser Prozentsatz an Windows-Rechnern hat die Jet-Engine schon installiert.
Ansonsten kann jeder sich die Jet-Engine aus dem Internet kostenlos downloaden.
http://support.microsoft.com/default...b;en-us;829558

Als ehemaliger VB-Programmierer würde ich am Anfang mit Access und ADO Komponenten anfangen und später auf andere Datenbanken wechseln.

[Marphy]

Hallo,

Zitat:

Zitat von shmia

Als ehemaliger VB-Programmierer würde ich am Anfang mit Access und ADO Komponenten anfangen und später auf andere Datenbanken wechseln.

Hmm, warum auf andere Datenbanken wechseln? Ist Access keine prof. Lösung? Zu lasche Performance?

Ach ja, ich will den Datenbankzugriff möglichst im Hintergrund laufen lassen (d.h. der User soll nicht direkt auf die DB z.B. mit einem DBGrid zugreifen können). Deshalb wäre ein Zugriff, welcher klassen- und nicht komponentengestützt läuft, wohl am Besten. :warn:

Gruß, Marco

[shmia]

Zitat:

Zitat von Marphy

Hmm, warum auf andere Datenbanken wechseln? Ist Access keine prof. Lösung? Zu lasche Performance?

Na, ja, Access ist eine reine Desktop-Datenbank.
Mehrplatzzugriff kann problematisch werden. Wenn die Access-DB über ~ 150MB anwächst bricht die Performance über ein 10MBit Netzwerk stark ein.

Zitat:

Zitat von Marphy

Ach ja, ich will den Datenbankzugriff möglichst im Hintergrund laufen lassen (d.h. der User soll nicht direkt auf die DB z.B. mit einem DBGrid zugreifen können). Deshalb wäre ein Zugriff, welcher klassen- und nicht komponentengestützt läuft, wohl am Besten. :warn:

Das bedeutet aber nur den Verzicht auf datensensitive Controls (die beginnen alle mit TDB und liegen auf der Seite "Datensteuerung").
Der Datenbankzugriff über (ADO)-Komponenten ist trotzdem sehr sinnvoll, da er viel Arbeit spart.

[Bernhard Geyer]

Zitat:

Zitat von Marphy

Mein Programm soll auf eine Datenbank zugreifen, die in einer Datei mehrere Tabellen bündelt. Dazu bietet sich die Access-Datenbank eigentlich an? Nun soll das ganze auch möglichst ohne Engine laufen (sonst wird das Setup zu groß). Mit DAO soll das funktionieren, ist aber recht unkomfortabel.

Für eine leicht zu verteilende und kleine DB-Engin würde ich dir ADS Local Server empfehlen.

Auch wenn die JET-Engine auf den meisten Rechnern schon vorliegt, spricht doch einiges dagegen:
- Möglichkeit der DLL-Hölle (Ist wirklich immer die passende Jet/MDAC/ADO-Version installiert?)
- Wird von M$ nicht mehr weiterentwickelt und könnte schon mit der nächsten Windows-Version nicht mehr defaultmäßig installiert sein

[Phoenix]

Zitat:

Zitat von Bernhard Geyer

- Wird von M$ nicht mehr weiterentwickelt und könnte schon mit der nächsten Windows-Version nicht mehr defaultmäßig installiert sein

Access soll ab der nächsten Office-Version auch kein Frontend für JET sein, sondern direkt für den SQL Server 2005 Express Edition, der diesen Sommer herauskommen soll.

[Marphy]

Hallo,

Zitat:

Zitat von Bernhard Geyer

Für eine leicht zu verteilende und kleine DB-Engin würde ich dir ADS Local Server empfehlen.

Da mein Programm Freeware ist, kommt eine kostenpflichtige Lösung nicht in Frage...

Hmm, wenn wir nun mal die Voraussetzung "keine DB-Engine" weglassen würden, was würdet ihr dann empfehlen?

Voraussetungen:

• Mehrere Tabellen und große Datenmengen (> 1 GB) sollen (ggf. komprimiert) in einer einzigen Datei zusammengefasst werden.
• Hohe Performance (> 50.000 Einträge).
• Möglichst BS-unabhängig (d.h. sollte von Win 95 über Win NT bis hin zu Win XP laufen können).
• DB ist lokal (d.h. keine komplizierten Netzwerkzugriffe, die DB wird quasi "nur" als "Datenfile" benutzt).
• Das ganze System sollte möglichst schlank sein!

Vielen Dank für eure bisherigen und zukünftigen Antowrten!

Gruß, Marco :gruebel:

[Bernhard Geyer]

Zitat:

Zitat von Marphy

Da mein Programm Freeware ist, kommt eine kostenpflichtige Lösung nicht in Frage..

ADS Local Server ist kostenlos. Der "richtige" ADS Server kostet geld

- Große Datenmenge geht. Haben schon Daten mit 4 GB im Einsatz. Bei NTFS sind Tabellengrößen >> 4 GB möglich
- Einzel-Datei ist nicht möglich (aber ein Verzeichnis ist ja nicht so schlimm)
- Performance sehr gut
- Läuft von Win95-2003
- Läuft als Desktop-Datenbank
- ist mit (aktuell) ca. 2 MB für 2 DLL's und 2 (oder warens 3) Konfigurationsdateien sehr schlank

[urs.liska]

Und natürlich auch mal wieder Firebird
Firebird-Homepage.
Sehr gut skalierbar, vom kleinsten Einzelplatzprojekt bis zum großen Firmennetzwerk (z.B. läuft die gesamte Infrastruktur der Deutschen PresseAgentur damit).
Als Embedded Server läuft er mit Minimalinstallation (nur eine DLL und ein paar Konfigurationsdateien, kein Registry-Eingriff).
OpenSource, also kostenlos.
Es gibt OpenSource-Zugriffskomponenten für Delphi (z.B. UIB, ZEOS), also auch das kostenlos. Die greifen direkt auf die Firebird-API zu, also kein Bedarf für BDE, ODBC oder sonstige Zwischenschichten.
Läuft neben den div. Windows-Versionen auch unter Linux.

MfG
Urs

[Marphy]

Hallo Bernhard, hallo Urs,

Zitat:

Zitat von Bernhard Geyer

ADS Local Server ist kostenlos. Der "richtige" ADS Server kostet geld

Wirklich? Dann habe ich wohl den Download-Link übersehen...

Zitat:

Zitat von Bernhard Geyer

- Einzel-Datei ist nicht möglich (aber ein Verzeichnis ist ja nicht so schlimm)

Nun, eine Einzeldatei wäre schon am Besten, aber zur Not tut's auch ein Verzeichnis.

Zitat:

Zitat von Bernhard Geyer

- ist mit (aktuell) ca. 2 MB für 2 DLL's und 2 (oder warens 3) Konfigurationsdateien sehr schlank

Gut, das ist vertretbar. Aber wie läuft das mit der Lizenz ab? Kann man die Programm-Files im eigenen Setup weitergeben?

Ach ja: Wie wird eigentlich von Delphi aus auf die Datenbank zugegriffen?

Zitat:

Zitat von urs.liska

Und natürlich auch mal wieder Firebird

Klingt gut. Können bei diesem DB-System access-ähnlich mehrere Tabellen zu einer Datei zusammengefasst werden?

Vielen Dank für eure Geduld und Bemühungen,
Marco :zwinker:

[Bernhard Geyer]

Zitat:

Zitat von Marphy

Zitat:

Zitat von Bernhard Geyer

- ist mit (aktuell) ca. 2 MB für 2 DLL's und 2 (oder warens 3) Konfigurationsdateien sehr schlank

Gut, das ist vertretbar. Aber wie läuft das mit der Lizenz ab? Kann man die Programm-Files im eigenen Setup weitergeben?

Ja. Sonst wärs ja als kostenloses Programm sinnlos.

Zitat:

Zitat von Marphy

Ach ja: Wie wird eigentlich von Delphi aus auf die Datenbank zugegriffen?

Wie mit BDE/ADO auch. Es werden Komponenten in der IDE installiert die fast die gleiche Schnittstelle wie TDatabase/TTabel/TQuery haben.

[Alter Mann]

Hallo,

wie wärs mit SQLite? Die DB ist eine Datei und benötigt eine (1) DLL.

[urs.liska]

Zitat:

Zitat von Marphy

Hallo Bernhard, hallo Urs,
...

Zitat:

Zitat von urs.liska

Und natürlich auch mal wieder Firebird

Klingt gut. Können bei diesem DB-System access-ähnlich mehrere Tabellen zu einer Datei zusammengefasst werden?

Eine Firebird-Datenbank ist im Normalfall eine einzelne Datei, die alle Elemente beinhaltet. Nicht "access-ähnlich" ist Firebird in der Hinsicht, dass es sich um einen ausgewachsenen SQL-Server handelt.

Und nochmals zum Delphi-Zugriff auf so eine Datenbank:
Es gibt eine Reihe von Komponentensammlungen, mit denen man das realisieren kann.
Alle greifen direkt auf das Firebird-API zu, so dass keine Sachen wie BDE oder ODBC vorhanden sein müssen.
Zwei OpenSource-Sammlungen gibt es: "Unified Interbase" und "ZEOS-Lib".
Außerdem gibt es zwei kommerzielle Pakete: FIBPlus und IBObjects. Bei beiden muss man als Entwickler eine Lizenz erwerben, kann das Programm aber ohne Gebühren weitergeben. IBObjects bietet darüber hinaus auch an, sich um eine kostenlose Lizenz zu bewerben, solange man mit den damit erstellten Programmen kein Geld verdient (sehr nett, nicht?).
In allen Fällen braucht man mindestens Delphi Professional, wenn man mit den datensensitiven Steuerelementen arbeiten will.
IBObjects liefert allerdings auch eine Menge eigener visueller Komponenten mit, so dass man auch mit Delphi Personal arbeiten könnte (man hat sich dann aber von Drittanbietern abgeschnitten).


HTH
Urs

[Robert_G]

Zitat:

Zitat von Marphy

• Mehrere Tabellen und große Datenmengen (> 1 GB) sollen (ggf. komprimiert) in einer einzigen Datei zusammengefasst werden.

Du wolltest 1GB in eine Jet-DB stecken? :shock:
btw: Firebird steckt 1GB einfach so weg.

Zitat:

Zitat von Marphy

• Hohe Performance (> 50.000 Einträge).

Das bezweifle ich ernsthaft.
Die einzigen Situationen in denen ich eine so große Anzahl Datensätze abgefragt habe waren Exports oder Replikationen.

Zitat:

Zitat von Marphy

• DB ist lokal (d.h. keine komplizierten Netzwerkzugriffe, die DB wird quasi "nur" als "Datenfile" benutzt).

Das schließt schon vom Konzept mehrere Benutzer aus. ;) (Kommt mir bitte nicht damit, dass man auch lokale DBs im Mehrbenutzerbetrieb fahren "könnte" ;) )

Zitat:

Zitat von Marphy

• Das ganze System sollte möglichst schlank sein!

Firebird!

Zitat:

Zitat von urs.liska

Sehr gut skalierbar, vom kleinsten Einzelplatzprojekt bis zum großen Firmennetzwerk.

Firebird mag ganz cool sein, aber er ist nicht wirklich skalierbar. ;)
Du kannst Tabellen nicht partitionieren oder Inidizes, Daten und Temp auf unterschiedliche Platten lagern.
Natürlich gibt es auch keinen Parallel server modus, das wäre nämlich wirkliche Skalierbarkeit. ;)
Wenn du damit Mehrprozessorsysteme meinst: Ja klar, dadurch ist eine gewisse Skalierbarkeit gewährleistet.

Versteht mich nicht falsch: Für einen Ersatz zu Jet ist FB natürlich wie ein Lotus Esprit verglichen mit einem Trabi. :mrgreen:

[urs.liska]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von urs.liska

Sehr gut skalierbar, vom kleinsten Einzelplatzprojekt bis zum großen Firmennetzwerk.

Firebird mag ganz cool sein, aber er ist nicht wirklich skalierbar. ;)
Du kannst Tabellen nicht partitionieren oder Inidizes, Daten und Temp auf unterschiedliche Platten lagern.
Natürlich gibt es auch keinen Parallel server modus, das wäre nämlich wirkliche Skalierbarkeit. ;)
Wenn du damit Mehrprozessorsysteme meinst: Ja klar, dadurch ist eine gewisse Skalierbarkeit gewährleistet.

Es mag sein, dass ich hier über etwas geschrieben habe, das ich nicht wirklich verstehe. Ich habe letztlich nur den Eindruck wiedergegeben, den ich von einer kürzlichen Diskussion auf der Firebird-support-Mailingliste erhalten habe.
Der Begriff "Skalierbarkeit" scheint mir aber auch i.A. etwas mehrdeutig verwendet zu werden.
Was ich meinte, war – sicherlich nicht ganz korrekt im Gebrauch des Wortes –: Firebird kann in ausgesprochen verschieden dimensionierten Anwendungen zum Einsatz kommen.
Neben der geannten DPA sowie diversen Universitäten wurde in dieser Diskussion auch der Fall einer amerikanischen Telefongesellschaft beschrieben, die alle Telefonatdaten mit Firebird speichert. Dabei kommen hunderttausende von Transaktionen pro Stunde zusammen, und es können für jeden Kunden bis zu sechs Jahren zurückliegende Rechnungen erstellt werden. Derjenige, der diese Datenbank betreut, führte ins Feld, dass der Schlüssel zur "Skalierbarkeit" das Datenbankdesign sei und erst in zweiter Linie die verwendete Soft- und Hardware.

Was ich damit letztlich nur zum Ausdruck bringen wollte, war, dass Firebird für den gewünschten Zweck mit Sicherheit gerüstet ist (und gleichzeitig keine Komplikationen verursacht, wenn man ihn als Entwickler auf seinem schnöden kleinen Einzelplatz laufen hat...

MfG
Urs

[Luckie]

Also wenn ich eine Microsoft Access Datenbank ansprechen sollte, gerade dann wäre meine erste Wahl Visual Basic, denn gerade im Zusammenspiel mit Anwendungen aus dem eigenen Haus fällt vieles mit Visual Basic leichter.

[Leuselator]

Abtrünniger - man schmeisse den Purschen Zu Poden! :mrgreen:

[urs.liska]

Zitat:

Zitat von Leuselator

Abtrünniger - man schmeisse den Purschen Zu Poden! :mrgreen:

Nur weil er die heilige Inkontinentia nicht ausgelacht hat???