Announcement: there is an English version of this forum on Hallo Zusammen ich habe eine "SQLite" DatenBank erstellt. Auf dieses Datenbank werden zwei Systeme zugreifen. Einmal mit Labview und Visual Studio C++. Kommt eigentlich SQLIte damit klar oder ist das Kritisch? Ich bin noch in der Spezifikationphase. Was ich noch vergessen habe: 1) Von Labview Seite wird die DB nur eingelesen 2) Von C++ werden Messdaten geschrieben danke in voraus
Wenn Betriebssystem und Dateisystem das File Locking korrekt implementieren, gibt es kein Problem. (Solche Fehler findet man meist bei Netzwerk-Dateisystemen.)
Clemens L. schrieb: > das File Locking korrekt > implementieren Was meinst du damit? Mir ist wichtig, dass die beide Systeme sich gegenseitig nicht stören sollen. Ich meine das Schreiben von System1 soll einwandfei sei und auch genau so das Einlesen von System soll auch flott und problemlos laufen
Bern_Gast schrieb: > Clemens L. schrieb: >> das File Locking korrekt >> implementieren > > Was meinst du damit? > > Mir ist wichtig, dass die beide Systeme sich gegenseitig nicht stören > sollen. > > Ich meine das Schreiben von System1 soll einwandfei sei und auch genau > so das Einlesen von System soll auch flott und problemlos laufen Ich denke die entscheidende Frage ist, ist es vorgesehen bzw. kann es irgendwie passieren, dass beide Programm gleichzeitig auf die DB Datei zugreifen wollen?
Bern_Gast schrieb: > ich habe eine "SQLite" DatenBank erstellt. > Auf dieses Datenbank werden zwei Systeme zugreifen. > Einmal mit Labview und Visual Studio C++. > > Kommt eigentlich SQLIte damit klar oder ist das Kritisch? Steht im Manual: https://www.sqlite.org/lockingv3.html
Scelumbro schrieb: > Ich denke die entscheidende Frage ist, ist es vorgesehen bzw. kann es > irgendwie passieren, dass beide Programm gleichzeitig auf die DB Datei > zugreifen wollen? ... und vor allem wie deine definition von GLEICHZEITIG ist, wenn beides in einem ms Slot passieren kann sollte das kein Problem darstellen.
Man kann für jedes SQLite-SQL-Kommando einen timeout setzen, SQLite führt das Teil dann aus wenn es geht. zB eine immmediate transaction. Datenbanken kann man auch read-only öffnen.
Scelumbro schrieb: > Ich denke die entscheidende Frage ist, ist es vorgesehen bzw. kann es > irgendwie passieren, dass beide Programm gleichzeitig auf die DB Datei > zugreifen wollen? 100% ausschliessen kann ich nicht.
Moin, bisher dachte ich immer; Mit einer Datenbank kommuniziert man über APIs. Und eine Datenbank ist Multiuserfähig. So zumindest die SQL Datenbanken mit denen ich täglich arbeite. Ich habe eine DB die wird lesen und schreiben von Java, PHP und C Clients bearbeitet. Die Anzahl der User liegt im Mittel bei 80 Usern. Deshalb nimmt man Datenbank Systeme. Um den Dateizugriff kümmert sich das System. Oder etwa nicht?
Mit dem DataBase geschieht folgende:
System1:
1)DataBase wird nur geöffnet.
2)SQL Statment "Select" wird ausgeführt (also nur Read-mode).
3)Database schliessen
System2:
1)Database wird geöffnet.
2)Messadaten in DaaBase schreiben
3) DataBase schliessen
--> Dieses Ablauf wird sich stets wiederholen.
Also die reihenfolge ist festgelegt und es ist fast unmöglich,
dass die beide Systeme gleichzeitig auf die DB zugegriffen wird.
Data schrieb: > Oder etwa nicht? bei SQLIte gibt es aber kein Datenbanksystem. Die Datenbank ist komplett im Treiber implementiert. Wenn mehre User auf eine Datei zugreifen, dann gibt es keinen gemeinsamen DB-Prozess der die zugriffe koordiniert. Das muss jeder Prozess mit Hilfe vom file-locking machen. Aus dem Grund wird es bei mehre Usern nicht wirklich schnell werden
Bern_Gast schrieb: > 1)DataBase wird nur geöffnet. > 2)SQL Statment "Select" wird ausgeführt (also nur Read-mode). > 3)Database schliessen warum immer öffnen und schließen? Ich dachte es soll bei dir schnell sein? Damit müssen ja Indizes ständig neu geladen werden.
Peter II schrieb: > warum immer öffnen und schließen? Ich dachte es soll bei dir schnell > sein? Damit müssen ja Indizes ständig neu geladen werden. Grund dafür, dass die dataBase von zwei unterschiedliche Systeme zugegriffen wird. Schnell muss es auch sein.
Bern_Gast schrieb: > Grund dafür, dass die dataBase von zwei unterschiedliche Systeme > zugegriffen wird. das bekommt SQLLite auch so hin
MoinMoin, Bern_Gast schrieb: > Kommt eigentlich SQLIte damit klar oder ist das Kritisch? > Ich bin noch in der Spezifikationphase. ja ist möglich, Erklärung kommt gleich... Klaus P. schrieb: > Steht im Manual: https://www.sqlite.org/lockingv3.html Jupp, hier wird der Mechanismus erläutert, der da greift... Peter II schrieb: > bei SQLIte gibt es aber kein Datenbanksystem. Die Datenbank ist komplett > im Treiber implementiert. naja, SQLite ist schon eine Datenbank, eine sogenannte "eingebettete" Datenbank. Und ja, die Zugriffsschicht ist nicht in einem zentralen Dienst, wie z.B. bei Oracle, MySQL etc., implementiert, der die Zugriffe koordiniert. Vielmehr gibt es eine API, die jeder beteiligte Prozess verwenden sollte und in der auch Mechanismen zur Zugriffssteuerung auf die DB zur Verfügung gestellt werden (und auch richtig angewendet werden sollten, um Dateninkonsistenzen zu vermeiden!). Peter II schrieb: > Wenn mehre User auf eine Datei zugreifen, dann gibt es keinen > gemeinsamen DB-Prozess der die zugriffe koordiniert. Das muss jeder > Prozess mit Hilfe vom file-locking machen. Nein, nicht das "File-Locking" des OS ist da entscheidend, sondern eben die erwähnten Mechanismen, die die die API zur Verfügung stellt...! Ich verwende aus verschiedenen Gründen, teilweise historisch bedingt, auch eine SQLite-DB zur Aufzeichnung und Bereitstellung von Messwerten. Dabei spielen ebenfalls mehrere unabhängige Prozesse im System (teilweise über mehrere Rechner verteilt) mit. Beim Schreiben von Daten in die DB wird, durch die API ein Lock-Flag in der SQLite-DB selbst gesetzt. Bei jedem schreibenden und lesenden Zugriff wird durch die API dieses Flag abgefragt. Ist es gesetzt, wird eine entsprechende Fehlermeldung generiert, auf die im entsprechenden Programm sinnvoll reagiert werden sollte! Für einen schreibenden Prozess sollte es also z.B. bedeuten, dass er die Schreibanforderung puffern und es später noch einmal versuchen muss. Dieses Lock-Flag wird, nebenbei, nicht nur bei schreibenden Zugriffen gesetzt, sondern z.B. bei einem SQLite-internen Dump, Backup oder einer gesetzten Transaktion, bei dem die Daten auch konsistent bleiben sollen. Ich habe die Sache sogar soweit getrieben, dass ich seit neuesten die Erfassung der Messwerte und das Schreiben in die DB auf zwei Prozesse verteilt habe. Die Prozesse kommunizieren via TCP/IP miteinander. Der Erfassungsprozess sendet also seine Insert-Statments zum Schreibprozess, der diese dann, wenn möglich, in die DB hämmert. Kann er dies nicht kann (z.B. DB locked), sendet er eine entsprechende Fehlermeldung an den Erfassungsprozess zurück, der die Inserts dann puffert und es irgendwann nochmal versucht. Das hat dann auch den Charme, dass man den "Schreiber" einfach mal stoppen kann und Wartungsaktionen o.ä. auf der DB durchführen kann, ohne dass Messdaten verloren gehen... Ich habe letztes Jahr mal auf verschiedenen Linux-Veranstaltungen einen Vortrag zu dem Thema gehalten, hier die Folien dazu: https://chemnitzer.linux-tage.de/2015/de/programm/beitrag/144 Grüße Uwe
Bern_Gast schrieb: > Clemens L. schrieb: >> das File Locking korrekt >> implementieren > > Was meinst du damit? Dass es in der Praxis meist läuft. Ausnahmen sind irgendwelche NAS, wo Locking ausgeschaltet wird, damit Benchmarks schneller laufen, oder nicht korrekt konfigurierte NFS-Implementationen, oder Windows-Systeme, die sich zwischendurch aufhängen (oplocks in SMB setzen voraus, dass sich alle Systeme schnell genug melden). Siehe auch http://www.sqlite.org/howtocorrupt.html.
Hi Zusammen, ich habe folgende Problem: Änderung der DB werden nicht gechekt, wenn ich diese ändere. Die DB ist immer gleichgeblieben, obwohl sie nicht mehr aktuell ist.
Aha. Gechekt. Neuer IT-Slang ? Geht's auch in verständlich ? ;)
Joachim D. schrieb: > Aha. Gechekt. Neuer IT-Slang ? Geht's auch in verständlich ? ;) Sorry Änderung der DB werden nicht gemerkt
Bern_Gast schrieb: > Änderung der DB werden nicht gemerkt von wem? Was ist wenn du das Programm neu startest sind sie dann drin? commit vergessen?
Bern_Gast schrieb: > --> Dieses Ablauf wird sich stets wiederholen. > Also die reihenfolge ist festgelegt und es ist fast unmöglich, > dass die beide Systeme gleichzeitig auf die DB zugegriffen wird. Die fiesesten Bugs, die es gibt, sind die, deren Auftreten "fast unmöglich" ist.
Rolf M. schrieb: > Bern_Gast schrieb: >> --> Dieses Ablauf wird sich stets wiederholen. >> Also die reihenfolge ist festgelegt und es ist fast unmöglich, >> dass die beide Systeme gleichzeitig auf die DB zugegriffen wird. > > Die fiesesten Bugs, die es gibt, sind die, deren Auftreten "fast > unmöglich" ist. An der stelle gibt das aber kein Bug sondern einfach nur nen klleines bisschen wartezeit wegen dem lock :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.