Delphi-PRAXiS - Alternative zu SQLite

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Cross-Platform-Entwicklung (https://www.delphipraxis.net/91-cross-platform-entwicklung/)

- - Alternative zu SQLite (https://www.delphipraxis.net/192999-alternative-zu-sqlite.html)

Alternative zu SQLite

Hallo zusammen,

ich verwende für meine Apps seit der ersten Firemonkey-Version immer SQLite als Datenbank.
Leider muss ich feststellen, dass besonders bei Android der Zugriff auf die DB immer wieder Fehler auswirft, da mein Hauptthread und der Synchronisierung-Thread auf diese zugreifen.
bei Lockmode gibt es verschiedene Einstellungen, wobei nur die Exclusive funktioniert. Bei "normal" kann es bis zur Zerstörung der DB führen.
Und wie gesagt wir sprechen hier vor allem von Android. Auf iOS hab ich da praktisch keine Probleme.

Was würdet ihr empfehlen als Alternative zur SQLite.
Wie schaut es mit zb. Interbase lizenztechnisch aus.

bin für jeden Tipp dankbar.

Gruß
Gebhard

AW: Alternative zu SQLite

InterBase Lite (IBLite) darf kostenfrei mit einer Android/iOS App ausgeliefert werden:

http://docwiki.embarcadero.com/RADSt...Go-Testversion

https://www.embarcadero.com/products...oduct-editions

Wenn einem die Features der IBLite nicht reichen: germany.info@embarcadero.com bzw Tel 06103-3866-0

AW: Alternative zu SQLite

https://community.embarcadero.com/bl...d-and-ios-apps

Ich könntem mir vorstellen das es auch

Firebird FbEmbedded auf iOS und Android schaffen könnte.
Habe es aber nicht gecheckt.

Trotzdem würd ich versuchen auf Sqlite zu bleiben, das scheint mir eigentlich der deFacto Standard für local DB zu sein.
Vielleicht ist es ja nur eine etwas andere ProgrammStruktur die helfen könnte.

Rollo

AW: Alternative zu SQLite

Die Probleme kamen offensichtlich nicht von SQLite.
Bei Delphi ist Android seit Tokyo 10.2 einfach nur Schrott.

Ich habe eben mit Delphi 10.1 auf Android kompiliert - das hat einwandfrei funktioniert.
Ich habe 3 Apps im Produktivbetrieb und alle Androidversionen sind seit Delphi 10.2 Schrott.

Jetzt habe ich wenigstens wieder lauffähige Versionen online.

@MEissing, Idera, Embarcadero:
macht in Zukunft bitte nie mehr so einen Schrott.
Dann sagt uns doch, dass Tokyo 10.2 nur für Linux geeignet ist, dann hätte ich nicht mehr als 5 Mann-Tage in die Fehlersuchte investiert, für die ich nichts kann....
Ich und vermutlich zigtausend andere zahlen Euch richtig viel Geld Jahr für Jahr.
Ich bin wirklich stinksauer...

Gebhard

AW: Alternative zu SQLite

Zitat:

Zitat von braunbaer (Beitrag 1374004)

da mein Hauptthread und der Synchronisierung-Thread auf diese zugreifen.

Ich denke das ist genau das Problem...

Ich würde alle Datenbank Zugriffe in einem Thread laufen lassen und den Zugriff über diesen Thread serialisieren...

(So mache ich es)

Keine Probleme...

Mavarik

AW: Alternative zu SQLite

Zitat:

Zitat von braunbaer (Beitrag 1374004)

da mein Hauptthread und der Synchronisierung-Thread auf diese zugreifen.

Über die selbe Connection oder je Thread Eine?
Kann die Connection auch mit Multithread umgehen? (wenn eine Connection)
Und letztendlich, kann die DB grundsätzlich multithreading? (das ist fast immer möglich)

Zitat:

Ich würde alle Datenbank Zugriffe in einem Thread laufen lassen und den Zugriff über diesen Thread serialisieren...
(So mache ich es)
Keine Probleme...

Wenn DataSets an der VCL hängen, dann meinst du doch bestimmt den Haupthtread?

Es kann sein, dass Zugriffe asynchron sind, also nach/außerhalb "deiner" Sperre erneut zugreifen.
z.B. bei Grids/DataSources mit Fetching, also wo beim Open (ausführen des SELECT) nicht sofort alle Daten geholt werden, sondern z.B. immer nur der Teil welcher grade im Grid sichtbar ist ... scrollst du dann im Grid, werden dabei dann die fehlenden Daten gezogen.
Das DBMS hält in diesem Fall das ResultSet so lange bei sich geladen, bis das Programm die Verbindung zu diesem ResultSet beendet.