firebird nach sqlite

[khh]

Hallo zusammen,
ich möchte eine Light-Version unserer WAWI erstellen und dazu SQLite nutzen.
Hat jemand Erfahrung damit ne Firebird -db auf sqlite zu portieren.

Ich danke euch

[Morphie]

Wobei hast du denn Probleme?
Hat das einen bestimmten Grund, warum du SQLite nehmen willst?
Wenn du sowieso schon Firebird verwendest, dann würde ich an deiner Stelle einfach auf Embedded umstellen...

[khh]

Zitat:

Zitat von Morphie (Beitrag 1171911)

Wobei hast du denn Probleme?
Hat das einen bestimmten Grund, warum du SQLite nehmen willst?
Wenn du sowieso schon Firebird verwendest, dann würde ich an deiner Stelle einfach auf Embedded umstellen...

ich möchte die DB integrieren ohne ein separates Programm installieren zu müssen.
An embedded hab ich nicht gedacht, danke für den Tipp

[blackfin]

Zitat:

ich möchte die DB integrieren ohne ein separates Programm installieren zu müssen.

Genau dafür ist die Firebird embedded da :-)

Die fbembed.dll musst du allerdings separat zu deiner EXE mitliefern. (ausser, du bindest sie in einer virtuellen Umgebung wie z.B. BoxedApp ein)

Ich würde auch zum FB embedded raten, er ist performanter als SQLite, unglaublich robust, hat eine fast vollständige SQL-92 Implementation und bietet im Gegensatz zur SQLite auch Stored Procedures.
Allerdings ist die DLL um einiges größer:
SQLite 3.7 DLL: 586kB
Firebird Embedded 2.5 DLL: 3.6MB

Ein Nachteil der FB embedded ist, dass nur ein Prozess gleichzeitig auf die Datenbank zugreifen kann. Wenn du gleichzeitigen Zugriff auf die Datenbank von mehreren lokalen Prozessen oder Programm-Instanzen brauchst, ist SQLite die bessere Wahl.
(Edit: Die FB 2.5 bietet das zwar nun, aber in der Praxis gibts damit wohl noch Probleme)
Ein Vorteil der FB embedded ist, dass du später, falls doch benötigt, ohne große Änderungen auch auf das große Client-/Server Modell umstellen kannst, was bei der SQLite nicht geht.

[WladiD]

Zitat:

Zitat von blackfin (Beitrag 1171915)

Ich würde auch zum FB embedded raten, er ist performanter als SQLite, ...

Ich weiss nicht, wie du darauf kommst, aber SQLite ist im Embedded-Bereich die "schnellste" DB. Nur für diesen Zweck wird sie auch entwickelt. Da steckt auch einiges an Interesse/Ressourcen seitens der namhaften Nutzer (Apple, Oracle, Mozilla etc.) Bei Firebird ist des Embed-Feature eher ein Nebenprodukt.

Hier mal ein ausführlicher Benchmark-Test. Ist zwar von 2006, aber dennoch interessant.

[blackfin]

Zitat:

SQLite ist im Embedded-Bereich die "schnellste" DB

das gilt sicher im Vergleich der SQLite zu Firebird Embedded Versionen kleiner als in der Version 2.x
Google mal nach aktuelleren Benchmarks, da schlägt die FB Embedded 2.5 die SQLite in vielen Fällen
(gut, in vielen Fällen auch nicht, es kommt, wie immer, auf den Anwendungsfall an :-))

Die SQLite hat durchaus manche Performance-Vorteile in gewissen Situationen, allerdings ist das Feature-Set ziemlich eingeschränkt im Vergleich zur Firebird Embedded.

So korrigere ich meine vorherige Aussage auf folgendes Statement:
Die FB Embedded ist im Feature-/Performance-verhältnis derzeit das Beste.

Firebird stinkt meiner Meinung generell dann ab, wenn es über TCP-Connections geht, da das Protokoll ziemlich "bloated" ist. Hat sich zwar in der 2.5 verbessert, aber ist immer noch ein Flaschenhals. Die embedded ist allerdings ziemlich fix.

[Iwo Asnet]

Zitat:

Zitat von WladiD (Beitrag 1171920)

Ich weiss nicht, wie du darauf kommst, aber SQLite ist im Embedded-Bereich die "schnellste" DB. Nur für diesen Zweck wird sie auch entwickelt.

Ich glaube, SQLite wurde vor dem Hintergrund eines kleinen Footprints entwickelt, denn sie heißt SQLite, nicht SQLFast

Ich kann mir zudem nicht vorstellen, das die DB bei sehr sehr großen Datenmengen noch performat läuft, dann dafür wurde sie nicht entwickelt.

Ich würde bei einer Entscheidung (FB, SQLite, etc.) auch die Zugriffskomponenten in Betracht ziehen: zumindest für ältere Delphi-Versionen (ohne Generics) habe ich keine zuverlässige und robuste Komponentensammlung gefunden. Die einzigen, die etwas taugen, umgehen TDataset-Derivate.

[blackfin]

Zitat:

...zumindest für ältere Delphi-Versionen (ohne Generics) habe ich keine zuverlässige und robuste Komponentensammlung gefunden...

Die derzeitige UniDAC-Version 4.1 gibt es von XE2 bis zu Delphi 6 und bietet Zugriff auf sowohl SQLite als auch FB embedded.
SQLite geht damit sogar ohne die SQLite-DLL ("direct access mode").

P.S.
Nein, ich verdiene nichts an UniDAC (im Gegenteil, ich habe sie mir selbst ja gekauft), auch wenn das inzwischen wohl bald so rüberkommt, weil ich sie hier oft empfehle....ich finde die Komponenten nur so gut, dass ich eine klare Empfehlung aussprechen kann.

[tsteinmaurer]

Wenn schon eine Firebird Datenbank im Einsatz ist, dann würde ich auch Firebird Embedded empfehlen, damit man sich nicht ein weiteres DB-Produkt mit ins Boot holt.

Zitat:

Ein Nachteil der FB embedded ist, dass nur ein Prozess gleichzeitig auf die Datenbank zugreifen kann. Wenn du gleichzeitigen Zugriff auf die Datenbank von mehreren lokalen Prozessen oder Programm-Instanzen brauchst, ist SQLite die bessere Wahl.
(Edit: Die FB 2.5 bietet das zwar nun, aber in der Praxis gibts damit wohl noch Probleme)

Ein konkurrierender Zugriff von mehrerer Embedded-Prozessen und regulären Firebird-Serverprozessen klappt mit Firebird 2.5 wunderbar, da Embedded in 2.5 auf der "SuperClassic" Architektur basiert. Vorausgesetzt, es werden keine 32-bit und 64-bit Prozesse gemixt und das Datenbankfile nicht übers LAN von einem Share zugegriffen wird.

[khh]

alsooo

ich hab jetzt einfach mal meine vorhandenen Programmen genommen und anstatt die "normale" fbclient.dll die vom embedded Server verwendet.
Laut Artikel aus dem EntwicklerMagazin muss man diese dazu einfach umbenennen, die Programmdatei, die dll sowie die firebird.conf und evtl. noch die Verzeichnisse \intl\ und \udf\ ins Programmverzeichnis ablegen.
Fertig.

Leider schmiert jedes meiner Porgramme so mit einer "access violation" ab.

Hat jemand nen anderen Plan, ohne dass ich die Programme durchsteppen muss?

Danke gruss KHH

[tsteinmaurer]

Mit "so einer access violation" Fehlermeldung können wir dir nicht weiterhelfen. Sorry.

[Morphie]

Je nach Zugriffskomponenten musst du diese auch noch entsprechend einstellen... Welche Properties hast du hier wie belegt?
Und welche Dateien hast du jetzt genau neben deine Anwendungsdaten gelegt? Ich würde mir einfach das komplette embedded-Paket herunterladen und in mein Anwendungsverzeichnis kopieren...

[DeddyH]

Reine Vermutung: Du bekommst keine Verbindung zur DB, greifst aber dann ungeprüft auf deren Felder zu. Versuch doch zuerst in einem kleinen Testprogramm, ob Du Dich überhaupt mit der DB verbinden kannst, oder ob da evtl. doch noch etwas fehlt (in der README_Embedded sollte genau beschrieben sein, was wo zu sein hat).

[TBx]

Zitat:

Zitat von khh (Beitrag 1171912)

ich möchte die DB integrieren ohne ein separates Programm installieren zu müssen.

Wer sagt denn, daß man den Firebirdserver installieren muß?
Den kannst Du auch einfach einkopieren und per Batch oder von Deinem Programm aus starten lassen.

Vielleicht ist das der einfachste Weg für Dein Ansinnen.

Gruß aus dem hohen Norden

[khh]

Zitat:

Zitat von Morphie (Beitrag 1172287)

Je nach Zugriffskomponenten musst du diese auch noch entsprechend einstellen... Welche Properties hast du hier wie belegt?
Und welche Dateien hast du jetzt genau neben deine Anwendungsdaten gelegt? Ich würde mir einfach das komplette embedded-Paket herunterladen und in mein Anwendungsverzeichnis kopieren...

Hab ich, ohne die dokus natürlich

[khh]

Zitat:

Zitat von DeddyH (Beitrag 1172288)

Reine Vermutung: Du bekommst keine Verbindung zur DB, greifst aber dann ungeprüft auf deren Felder zu. Versuch doch zuerst in einem kleinen Testprogramm, ob Du Dich überhaupt mit der DB verbinden kannst, oder ob da evtl. doch noch etwas fehlt (in der README_Embedded sollte genau beschrieben sein, was wo zu sein hat).

ich denke ich werd um ein Testprogramm wohl nicht herum kommen :-(

[khh]

alssoooo
Testprogramm erstellt, alle Files aus dem Embedded-Archiv ins Programmverzeichnis kopiert,
dll umbenannt.
Auf das Form ein dbgrid, ein datasource, eine zconnection sowie eine zquery.
In der Entwicklungsumgebung alles aktiv gesetzt - funktioniert, Daten werden im Grid angezeigt. :-)

Programmstart - crash :-(

Beim Step ergibt sich, dass die connection noch funktioniert, das Aktivieren der Query aber abschmiert.
Dass die richtige dll benutzt wird ist sicher, da ein externer Zugriff darauf mit der Meldung dll wird von programxy benutzt scheitert.
Wo kann ich noch den Fehler suchen ?

[blackfin]

Hast du die neueste embedded DLL (2.5) von Firebird genommen? Wenn ja, prüfe mal folgendes:

- Ist Zeos mit der 2.5er des Firebird überhaupt kompatibel?

- In deinem Eigangsposting steht, du hast bis jetzt die 2.1 des Firebird verwendet.
Hast du es mal mit der 2.1 embedded DLL (statt 2.5) versucht?

- In Den Zeos Connection-Params, steht das "Protocol" auch auf "firebirdd-2.x" ?
(wobei das x die Unterversion angibt..mein altes Zeos hier hat allerdings nur "firebirdd-2.0" als höchstes)

[DeddyH]

Auch noch wichtig für Embedded: Hostname (oder wie das bei ZEOS heißt) muss leer bleiben.

[khh]

Zitat:

Zitat von blackfin (Beitrag 1172331)

Hast du die neueste embedded DLL (2.5) von Firebird genommen? Wenn ja, prüfe mal folgendes:

- Ist Zeos mit der 2.5er des Firebird überhaupt kompatibel?

das wars :wall::wall:

ich danke euch und dir gewaltig.

Zeos in der Version 6.6 kann nur bis 2.1
Übrigens, ob hostname leer ist , oder nicht ist in der 2.1 anscheinend egal

Vielen Dank
Gruss KHH

[mkinzler]

Zitat:

Übrigens, ob hostname leer ist , oder nicht ist in der 2.1 anscheinend egal

Kann eigentlich nicht egal sein, da der Client daran entscheidet ob embedded oder Netprotokoll verwendet wird.

[khh]

Zitat:

Zitat von mkinzler (Beitrag 1172340)

Zitat:

Übrigens, ob hostname leer ist , oder nicht ist in der 2.1 anscheinend egal

Kann eigentlich nicht egal sein, da der Client daran entscheidet ob embedded oder Netprotokoll verwendet wird.

ok , du hast Recht, auf einem jungfräulichen Rechner musste hostname leer sein.

gruss khh