PureBoard

Hallo zusammen und ein gutes neues Jahr erst einmal,

In Ergänzung zu meinem letzten Thema http://www.purebasic.fr/german/viewtopi ... =3&t=29382 bezüglich einer Datenbank im Speicher erzeugen und verwenden frage ich mich,
ob es die Möglichkeit gibt eine unter PB erzeugte SQLite DB Datei auf einen Webserver hochzuladen und via PB SQLite Query direkt anzusprechen, so nach dem Motto: Der Vorteil wäre, man braucht die Daten nur an einer Stelle zu pflegen und könnte Sie vielen Anwendern zur Verfügung stellen. Ferner wäre die Installation eines ODBC Treibers nicht notwendig.
Leider klappt das so wie oben angegeben nicht. Sobald ich versuche die Datenbank anzusprechen, erhalte ich eine Fehlermeldung, dass die Datenbank nicht initialisiert ist.
Da ich kein Netzwerker bin wäre da ein wenig Schützenhilfe angebracht.

Hat da einer eine Idee oder einen Link zu, oder ist das alles zu blauäugig gedacht?

Danke schon mal für hilfreiche Rückantworten

Irgendwo hab ich mal gelesen, das eine SQLLite-Datenbank immer lokal sein sollte.

Aber auch ansonsten: Das HTTP-Protokoll ist nicht geeignet, um Dateien mit Fernzugriff zu verwalten. Falls überhaupt was passiert, wird die Datei gedownloaded und in Temp-Ordner gespeichert. Zudem weis ich nicht, ob SQLLite überhaupt darauf ausgelegt ist, das mehrere Instanzen gleichzeitig auf eine Datei zugreifen.

wenn man sich einen entsprechenden Server installiert, sollte das möglich sein. Hier eine kurze Übersicht:

http://www2.sqlite.org/cvstrac/wiki?p=SqliteNetwork

Allerdings würde ich davon abraten, SQL-Anweisungen so ohne weiteres via HTTP zu versenden. Da kann schnell mal ein "Drop Table" unterwegs sein...

Mein Tipp geht eher in die Richtung, ein kleines PB-CGI oder einen FastCgi-Server zu bauen (beides geht mit den neuen PB-CGI-Befehlen ab Version 5.40 recht einfach), über die Du dann gezielt und risikofrei Daten anfordern kannst.

Grüße ... Peter

@GPI und Kiffi Danke für Eure Antworten und Links. Ich schau es mir an.

Zudem weis ich nicht, ob SQLLite überhaupt darauf ausgelegt ist, das mehrere Instanzen gleichzeitig auf eine Datei zugreifen

Generell schreibenderweise nicht. Lesenderweise glaube ich aber schon.

Allerdings würde ich davon abraten, SQL-Anweisungen so ohne weiteres via HTTP zu versenden. Da kann schnell mal ein "Drop Table" unterwegs sein...

Korrekt, dessen bin ich mir bewusst.

Ziel ist es, die komplette DB vom Server in den Arbeitsspeicher des ausführenden Rechners zu laden und dort zu arbeiten. Das heißt im Umkerschluss, die DB wir ausgelesen und das wars dann auch schon.

Kiffi, mit webseitiger Programmierung kenn ich mich noch nicht so aus, hast du da mal so eine Minibeispiel? Wäre prima.

Vielen Dank

Mit webseitige Programmierung würde ich aufpassen, da kann man schnell was falsch machen und irgendwer nutzt das dann aus. Was willst du denn machen? Nur Lesen? Wie groß ist die Datenbank? Eventuell ist es klüger die downzuloaden und dann lokal drauf zuzugreifen. Du kannst ja mit einer zweiten sehr kleinen Datei eine Versionsnummer abspeichern, die du vor den Downloaden abfragst.

Danke GPI

Was willst du denn machen? Nur Lesen?

Ja, das hatte ich in meinem letzten Post so geschrieben

Eventuell ist es klüger die downzuloaden und dann lokal drauf zuzugreifen.

Das mache ich derzeit so, möchte aber Alternativen ausloten.

Du kannst ja mit einer zweiten sehr kleinen Datei eine Versionsnummer abspeichern, die du vor den Downloaden abfragst.

Das ist mein derzeitiger Stand der Vorgehensweise.

Wir vor schon erwähnt, Ich suche Alternativen.

Übrigens, die DB ist ca. 20 MB groß. Bekannterweise steckt da aber viel 'Luft' drin. Wie das bei DBs halt so ist.

LG
MenschMarkus

MenschMarkus hat geschrieben:Übrigens, die DB ist ca. 20 MB groß. Bekannterweise steckt da aber viel 'Luft' drin. Wie das bei DBs halt so ist.

Mit 7z vorher packen (Einstellungen Ultra nehmen)? Das sollte das Ding deutlich kleiner machen (Ich hab mal spaßeshalber die global-messag-db.sqlite von Firfox gepackt, von 15mb auf 2mb runter). PB kann ja mit 7z mittlerweile umgehen.

Mit 7z vorher packen

Nette Anregung, Danke

Leider kann ich die Datei dann nicht mehr zum direkten einlesen via 'OpenDatabase' verwenden. Ferner wäre ich dann wieder da wo ich jetzt bin, nämlich beim Herunterladen und entpacken.

Eine Alternative könnte ich mir noch vorstellen. Direkter Zugriff auf eine Serverseitige MySQL Datenbank, aber bitte ohne ODBC Treiberinstallation am Anwender Arbeitsplatz PC.

Über das Web ist generell keine so schlechte Idee. Mit Nginx und FastCGI wäre das eigentlich eine recht gute Sache. Das Problem dabei ist natürlich, das man sich erst in einen Webserver einarbeiten muss. Aber da der Webserver an sich ja schon fertig implementiert ist, hast du mit SSL- und FCGI-Plugin bereits alles, was du brauchst. Du musst dann nur dafür sorgen, das der Zugriff auf den Webservice sicher von statten geht (Authentifizierung ist definitiv von nöten). Handelt es sich um ein geschlossenes Intranet, dann kannste theoretisch auch das SSL weglassen.

Ich würde aber den Weg über das HTTP-Protokoll immer vorziehen, wobei ich als Backend da eher auf REST und PHP setzen würde, als da extra eine fcgi zu schreiben. Vor allem mit einer Sprache, in der es weder eine vernünftige Passwort-Funktion noch funktionierendes Session-Management und erst recht (und das ist für mich das größte Problem) die übergebenden Parameter schwammig implementiert wurden (keine Trennung von Post und Get und nur sehr schwer umzusetzende Stapelverarbeitung). Es fehlt aber noch viel mehr, auf das ich hier jetzt nicht unbedingt eingehen will. Aber kurz gesagt. Das neue Killerfeature hat sich beim testen im nachhinnein als lieblos reingeklatschte Nullnummer entpuppt.

Vorteil von HTTP ist eben, das die HTTP-Server das Protokoll vollständig unterstützen und man sich nicht selber darum kümmern muss. HTTP kann eigentlich alles, was für Client-Server Kommunikation von nöten ist. Einziger Umstand ist die Zustandslosigkeit, mit dem die Verbindungen nicht permanent offen bleiben. Die Server lassen sich mit entsprechenden Plugins um weitere Funktionen erweitern (zum Beispiel Verbindungsverschlüssellung mit Zertifikaten, zusätzliche Sprachinterpreter etc.). Alles Sachen, um die man nicht selber kümmern muss und bereits etabliert und getestet sind.

Ein weiterer Nachteil an dem Protokoll ist es, das es von PureBasic nicht nativ unterstützt wird. Man muss sich die libcurl aus den mitgelieferten Bibliotheken zugänglich machen, damit man ein einigermaßen gut implementiertes Request auch für https bekommt. Oder man muss es von Hand implementieren. Und das wird eklig. Daran habe ich mich selbst schon versucht.

Ich weiß leider nicht, in wie weit ein Netzlaufwerk sich im Vergleich zu einem lokalen Laufwerk verhält. Aber die einfachste Möglichkeit für eine im Netzwerk nutzbare Datenbank wäre ein Server-DBMS wie PostgreSQL und eine Direktverbindung an den Server, was allerdings vorraussetzt, das du dort in der Datenbank wirklich auch die Nutzerverwaltung durchführen und die Rechte dort entsprechend einschränken musst. Ich würde also auch gleich ein Frontendtool wie PGAdmin verwenden, damit die Datenbank-Einstellungen und Benutzer vernünftig verwalten kannst. Man sollte also schon ein wenig Knowhow mit DBMS haben, damit es einigermaßen sicher wird.

http://www.pgadmin.org/

MenschMarkus hat geschrieben:Kiffi, mit webseitiger Programmierung kenn ich mich noch nicht so aus, hast du da mal so eine Minibeispiel? Wäre prima.

zuvor eine Frage: Verfügst Du über einen eigenen Webserver, bzw. erlaubt Dein Webhoster Dir, eigene CGIs auf Deinem Webspace laufen zu lassen? Denn nur dann wäre (Fast-)CGI für Dich interessant.

MenschMarkus hat geschrieben:Übrigens, die DB ist ca. 20 MB groß. Bekannterweise steckt da aber viel 'Luft' drin. Wie das bei DBs halt so ist.

SQLite-Datenbanken haben (wie MS-Access-Datenbanken) die Eigenart, den Speicherplatz beim Löschen oder Ändern von Datensätzen nicht automatisch freizugeben. Du kannst ja mal versuchen, ein "Vacuum" auf die Datenbank auszuführen: Was mir noch in Deinem ersten Posting aufgefallen ist:

MenschMarkus hat geschrieben:[...] Ferner wäre die Installation eines ODBC Treibers nicht notwendig. [...]

Für SQLite benötigst Du keinen ODBC-Treiber.

Grüße ... Peter