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