BVA-System

Heute möchte ich mich mit der Frage beschäftigen, wo eine Bildverwaltungssoftware die Bilddaten abspeichert. Prinzipiell gibt es 2 Möglichkeiten: die Bilder können mit den Metadaten zusammen in der Datenbank gespeichert werden. oder es kann in der Datenbank nur eine Referenz, bestehend aus Pfad+Dateiname des Bildes, abgelegt werden. Beide Methoden haben ihre Vorteile, aber auch Nachteile.  Da keine der Methoden frei von Nachteilen ist, kann man sich darüber streiten, welche Methode nun die bessere ist. Schlussendlich ist es also eine Entscheidung des Anwenders, welche Methode er bevorzugt.

Bevor ich auf die Vor- und Nachteile eingehe, möchte ich kurz schildern, welches Konzept das neue BVASystem verfolgt bzw. verfolgen wird. Es werden im BVASystem pro Datensatz 3 Bilder abgespeichert. Als erstes wäre da das Thumbnail, welches in der Bildliste angezeigt wird. Standardmäßig hat das Thumbnail eine maximale Bildhöhe von 200 Pixel. Weiterhin wird ein Vorschaubild gespeichert, welches angezeigt wird, wenn der Anwender das Bild im angepassten Zoommodus betrachtet. Es hat standardmäßig eine maximale Höhe von 800 Bildpunkten und lässt sich damit auch auf älteren Rechnern schnell laden und anzeigen. Sowohl das Thumbnail, als auch das Vorschaubild werden in der Datenbank gespeichert. Als drittes wird natürlich die Originalbilddatei gespeichert, welche angezeigt werden soll, sobald der Anwender den angepassten Zoommodus verlässt. Aktuell ist es so, das auch das Originalbild in der Datenbank abgelegt wird. Die Datenbankstruktur ist aber so angelegt, das anstelle des Bildes auch eine Referenz gespeichert werden kann. Der Anwender soll sich später  einmal in den Optionen aussuchen können, ob das Originalbild in der Datenbank oder als Referenz gespeichert werden soll.

Ich habe mich zu diesem Konzept entschieden, da ich mit dem Programm meine eigenen Bilder im Heimnetzwerk verwalte. Da ist es einfacher, wenn die Bilder zentral auf dem Server gespeichert werden, damit alle Rechner darauf zugreifen können. Durch meine kurze Begründung für das Konzept bin ich nun aber auch schon mittendrin bei den Vor- und Nachteilen der beiden Möglichkeiten.

Speicherung der Bilder in der Datenbank

Für die Speicherung der Bilder in der Datenbank spricht, das das Programm damit komplett netzwerkfähig wird. Es macht keinen Unterschied, ob der Datenbankserver lokal, im Heimnetzwerk oder gar im Internet liegt. Es kann immer auf die gleiche Art und Weise auf die Bilder zugegriffen werden. Ebenfalls vorteilhaft ist, das die eingestellten Daten zentral an einer Stelle gespeichert sind. Dadurch können die Daten leicht gesichert und bei einem Datenverlust auch leicht wiederhergestellt werden. Als dritter Vorteil fällt mir ein, das man das Berechtigungssystem der Datenbank nutzen kann, um unerlaubten Zugriff auf die Bilddaten zu verhindern. Bei einer lokalen Installation wird man dies wohl nicht benötigen, aber im Netzwerkbetrieb mit mehreren Nutzern kann dies schon von Bedeutung sein.

Nachteilig an der Speicherung der Bilder in der Datenbank ist, das die Bilder erst wieder  exportiert werden müssen, wenn man sie außerhalb der Bildverwaltung benötigt. Will man die Bilder beispielsweise an ein Fotolabor senden, so wird dies nicht auf direktem Wege funktionieren. Zuerst müssen die ausgewählten Bilder in ein temporäres Verzeichnis auf der Festplatte kopiert werden. Von dort können sie dann ans Fotolabor gesendet werden. Einige sehen dies aber auch als Vorteil, den die Originalbilddateien sind in der Datenbank dadurch sicher vor ungewollten Änderungen. Es geht ganz schnell, das man beispielsweise beim Drehen eines Bildes mit einem Bildbearbeitungsprogramm plötzlich den EXIF-Header des Bildes, der die Meta-Daten wie Aufnahmedatum oder Aufnahmeort enthält, verliert.

Von der Performance her ist die Speicherung der Bilddaten in der Datenbank langsamer als auf dem Dateisystem. Dies erklärt sich dadurch, das kein direkter Zugriff vom Programm auf die Bilddatei erfolgt. Der Zugriff erfolgt zweistufig: Das Programm stellt eine Anfrage an die Datenbank und diese liest dann die Bilddatei von der Festplatte. Häufig angezeigte Bilder wird die Datenbank im Arbeitsspeicher cachen und damit schneller ausliefern als das Dateisystem.

Als größten Nachteil für die Datenbankspeicherung sehe ich die starke Abhängigkeit von der Verwaltungssoftware. Wenn die Software von heut auf morgen nicht mehr weiterentwickelt wird, hat der Anwender ein Problem. Neuer Rechner, neues Betriebssystem und schon nützt einem nichtmal mehr ein Datenbackup, weil die alte Software einfach nicht mehr läuft. Man kann zwar mit Hilfe von Tools der Datenbankhersteller ebenfalls auf die Datenbank zugreifen, aber dafür benötigt man schon einiges an Fachwissen. Außerdem ist die Art von Datenzugriff nicht wirklich komfortabel.

Speicherung von Bildreferenzen

Bei der Speicherung von Bildreferenzen ist die Sache genau anders herum. Der Anwender behält weiterhin vollen Zugriff auf seine Bilder. Die mit der Verwaltungssoftware erstellten Bildbeschreibungen, speichert das Programm idealerweise direkt im Bild ab. Sollte die Software nicht mehr weiterentwickelt werden, oder der Anwender hat ein besseres Programm gefunden, so importiert er seine Bilder einfach mit samt den Bildbeschreibungen in das neue Programm. Auch kann der Anwender sofort auf seine Bilddaten zugreifen, wenn er sie an ein Fotolabor schicken möchte.

Der einfache Zugriff auf die Bilder ist aber auch der größte Nachteil der Bildreferenzen. Der Anwender kann zu jeder Zeit Bilder löschen, verschieben oder umbenennen. In der Datenbank der Verwaltungssoftware entstehen dadurch Datensätze, die keinem Bild mehr zugeordnet werden können. Im schlimsten Fall ist der Sinn der Verwaltungssoftware verfehlt, da der Anwender sein gesuchtes Bild nicht wiederfindet, weil er es vor ein paar Monaten in ein anderes Verzeichnis verschoben hat ohne dabei an die Bildverwaltung zu denken.

Eine Netzwerkfähigkeit ist mit Bildreferenzen nur bedingt erreichbar. Im lokalen Netzwerk kann man vielleicht noch mit Netzwerklaufwerken arbeiten um einen Zugriff von mehreren Rechnern aus zu gewährleisten. An der Stelle wird es aber bereits schwierig, ungewünschte Zugriffe auf die Bilder zu verbieten.

Fazit

Wie bereits oben gesagt, war für mich die Netzwerkfähigkeit der ausschlaggebende Punkt mich für die Speicherung der Bilder in der Datenbank zu entscheiden. Wie sieht es bei euch aus? Speichert ihr die Bilder in der Datenbank oder nutzt ihr nur Bildreferenzen?

In dem diesmaligen Entwicklungszyklus habe ich es geschafft, meinen alten Rekord von 12 abgearbeiteten Tickets in einer neuen Version zu brechen. Ganze 16 Punkte habe ich in den rund 2 Wochen geschafft. Ok, viele der Tickets hatten diesmal nicht so einen großen Umfang, aber der Teufel steckte oft in den Details. So war zum Beispiel die Überarbeitung des Popupmenüs der Bildliste etwas tricky. Je nachdem ob kein Bild, ein Bild oder mehrere Bilder markiert sind und ob das aktive Bild markiert ist oder nicht, werden unterschiedliche Beschriftungen im Popupmenü angezeigt.

Die größte Änderung, die ich hier extra erwähnen will, ist der Fingerprint. Wenn ein Bild in der Datenbank abgespeichert wird, so wird mit dem Bild eine Art Fingerabdruck erzeugt und mitgespeichert. Versucht der Anwender das Bild nun ein zweites Mal in der Datenbank abzulegen, so wird dies, aufgrund des bereits in der Datenbank vorhandenen Fingerprints, verhindert. Selbst wenn das Bild in der Zwischenzeit umbenannt wurde, wird trotzdem erkannt, das es sich um ein doppeltes Bild handelt.

Hauptdialog der Version 2.0.0.11

Die Details zu den Änderungen können, wie immer, im Bugtracker nachgeschlagen werden. Da der letzte Screenshot nun auch schon etwas älter war, habe ich heute einen neuen erstellt. Und zu guter Letzt habe ich heute noch, ebenfalls im Bugtracker, abgesteckt wohin die nächsten beiden BVASystem Versionen führen werden.

In der nächsten Version der Bilddatenbank möchte ich mich darum kümmern, das die Verbindung zur Datenbank nicht mehr über den Testbutton hergestellt werden muss.  Außerdem möchte ich die Möglichkeit schaffen, das das Programm als reiner Bildbetrachter nutzbar wird. Dabei soll, auch ohne Datenbankserver, der Anwender nicht von Fehlermeldungen genervt werden. In der übernächsten Version muss dann die Datenbankstruktur erweitert bzw. überarbeitet werden, damit Platz für neue Features ist. Im speziellen ist angedacht, das falsch ausgerichtete Bilder gedreht werden können und das der Orientierungssinn auch gespeichert wird.

Heute möchte ich die Gelegenheit nutzen, um die Frage zu beantworten, warum ich beim BVASystem auf ein Client-Server-Datenbankmodell gesetzt habe. Bevor ich jetzt aber groß in die Vor- und Nachteile einer Client-Server-Architektur einsteige, möchte ich kurz erklären, was das eigentlich ist.

Was ist ein Client-Server-System?

Wie der Name es sagt, besteht ein Client-Server-System aus 2 Komponenten, dem Client und dem Server. Bei beiden handelt es sich um eigenständige Programme, die in der Regel auf unterschiedlichen Rechnern in einem Netzwerk laufen. Es ist aber auch möglich, das Server und Client auf nur einem Rechner laufen. Der Server hat in der Regel keine eigene Oberfläche. Seine Aufgabe ist es, dem Client bestimmte Funktionen zur Verfügung zu stellen. Der Client ist das Programm, welches der Anwender gut kennen sollte. Der Client nutzt die Funktionen, die der Server zur Verfügung stellt und zeigt die Resultate dieser Funktionen dem Anwender an.

Beim BVASystem ist der Server ein Datenbankmanagementsystem, wie zum Beispiel das während der Entwicklung genutzte  MySQL.  Der Server hat hier die Aufgabe, die Fotos, die der Client dem Server übermittelt, zu speichern und zu einem späteren Zeitpunkt dem Nutzer wieder anzuzeigen. Eigentlich sollte es jetzt bereits klar sein, der Client ist in dem System das Programm, welches ich gerade programmiere.

Welche Vorteile und Nachteile hat ein Client-Server-System?

Für mich ist der größte Vorteil, das ich meine Fotos nur auf einem Server speichern muss. Ich bin im Besitz von mehreren Computern, die ich hier in einem Heimnetzwerk miteinander verbunden habe. Zum einen habe ich einen Standrechner, auf dem ich hier gerade diesen Text schreibe und zum zweiten habe ich einen Notebook, der mich begleitet, wenn ich mal unterwegs bin. Auf dem Standrechner habe ich den MySQL-Server installiert. Sowohl auf Standrechner, als auch auf dem Notebook habe das BVASystem installiert und so eingerichtet, das beide Rechner auf das Serverprogramm des Standrechners zugreifen können.

Ein Nachteil ist es, das auch, wenn man nur von einem Rechner aus seine Fotos verwalten will, man den Datenbankserver installieren muss. Gerade für Nutzer, die nicht so technikaffin sind, könnte es zu Schwierigkeiten in der Administration des Servers kommen. Auch ich hatte schon so meine Schwierigkeiten mit dem MySQL-Server: Server has gone away Weiterhin kann es von Nachteil sein, wenn man mit mehreren Clients auf die Fotos zugreifen will und dafür extra einen Rechner bereitstellen muss auf dem nur der Server läuft.

Ein weiterer Vorteil, für mich als Entwickler ist, das ich mit dem Client-Server-Modell auf standardisierte Server-Komponenten zurückgreifen kann. Damit lässt sich wunderbar, das von mir bereits beschriebene Schichtenmodell umsetzten. Ich muss also weniger Aufwand in die Entwicklung des Systems stecken. Aber auch für den Anwender hat dies einen Vorteil. Wenn ich morgen, aus welchem Grund auch immer, das BVASystem nicht mehr weiterentwickeln würde, dann könnte der Anwender weiterhin mit Service-Programmen, die mit dem Server ausgeliefert werden, auf seine Daten zugreifen und sie in eine Struktur überführen, die andere Programme lesen können.

Als nachteilig empfinde ich es, das die Bilder, die ich in der Datenbank gespeichert habe, nicht so ohne weiteres Bearbeiten kann. Wenn ich von mehreren Rechnern auf die Bilder zugreifen will, so muss ich diese direkt in der Datenbank abspeichern. Zur Bearbeitung muss ich die Bilder also erst aus der Datenbank extrahieren und anschließend wieder neu abspeichern. Um diesen Nachteil auszugleichen, hatte ich damals vor, das BVASystem mit Bildbearbeitungsfunktionen auszustatten. Mittlerweile bin ich davon aber weg gekommen, da dies den Rahmen eines Hobbyprojektes bei weitem sprengen würde.

Es ist wieder einmal Zeit, das BVASystem zu aktualisieren. Neu hinzugekommen in der Software ist dieses Mal ein System, für welches ich leider keinen sinnvollen deutschen Namen gefunden habe.

Worum geht es?

Die Bilder, die in einer Bildverwaltung archiviert werden sollen, müssen logischerweise irgendwie in das System eingefügt werden. Wer das alte BVASystem kennt, sollte wissen, das dies damals über einen Importdialog gelöst wurde. Während des Importierens war die Anwendung dann für den Anwender nicht weiter bedienbar.  Im neuen System dagegen soll der Import so ablaufen, das der Anwender währenddessen das Programm weiter bedienen kann.

Da ich alles immer möglichst allgemein halte, überlegte ich mir, was in einer Bildverwaltung noch so alles durchgeführt werden muss.   Gedacht habe ich zum Beispiel an das Löschen von Dateien, an das Kopieren von Dateien und natürlich an den In- und Export von Bilddaten. Also habe ich ein System entwickelt, das alle diese Aufgaben erledigen kann.

Worker

Der Anwender bekommt von dem System im Hintergrund relativ wenig mit, nur oben rechts in der Ecke kann der Status des Systems abgelesen werden. Relativ einfach ist dort zu erkennen, ob noch Aufgaben abzuarbeiten sind. Sofern Aufgaben vorhanden sind, ist durch eine sinkende Aufgabenanzeige zu erkennen, das das System arbeitet. Will der Anwender die Software beenden, wenn noch Aufgaben im System sind, wird natürlich eine Warnung angezeigt.

Da noch keine richtige Aufgabe für das System programmiert wurde, kann über den Knopf „WorkerTest“ das System mit 2 Testaufgaben bestückt werden. Dieser wird in rund 14 Tagen wieder verschwunden sein, da ich bis dahin richtige Aufgaben für das System umsetzen möchte.

Warum heißt das System nun „Worker“?

Die Funktionsweise des Systems hatte ich mir relativ schnell ausgedacht. Ich wollte etwas schaffen, das Aufgaben im Hintergrund der Anwendung abarbeitet und nur möglichst knapp dem Anwender mitteilt, was es gerade tut. Die Namenswahl war mir eigentlich recht egal. Dies änderte sich, als ich die Beschriftungen für den Dialogteil, der auf dem Bild zu sehen ist, festlegen wollte. Ich brauchte einen kurzen prägnanten Namen, der gut in das Dialogelement passt.

Den in der Informatik bekannten Fachbegriff Thread wollte ich nicht nehmen, da ein Normalanwender damit wohl kaum etwas anfangen kann. „Aufgabenbearbeitungssystem“ war für den kleinen Dialogbereich einfach zu lang. Der deutsche Begriff „Arbeiter“ klang irgendwie blöd. Also fiel meine Wahl auf dem Begriff „Worker“. Aber falls jemand eine bessere Idee hat, wie ich den „Worker“ nennen könnte, so soll er mir dies hier per Kommentar mitteilen. Danke.

Mit dem heutigen Tag ist wieder ein Meilenstein in der Entwicklung des BVASystems erreicht. Die Version 2.0.0.8 kann, wie immer, unter Download herruntergeladen werden. Vor wenigen Tagen berichtete ich, warum es wichtig ist, eine klare Trennung zwischen Oberfläche und den eigentlichen Daten herzustellen. Diese Trennung ist nun komplett umgesetzt. Der letzte direkte Zugriff der Oberfläche auf die Daten ist entfernt, alles läuft nun, so wie gewünscht, über die Datenschicht.

Gestern abend habe ich weiterhin die Roadmap für die nächsten 3 Entwicklungsetappen abgesteckt. Die nächste Version wird für mich etwas zum verschnaufen sein, denn ich will dort nur Änderungen an der Oberfläche vornehmen. Die Änderungen sollten nicht sonderlich kompliziert werden. Aber wenn sie gemacht sind, stärkt es die Bildbetrachter-Funktionen des BVASystems.

Anschließend kommt wieder etwas komplizierteres, welches ich in 2 Etappen umsetzen möchte. Ich möchte dann ein Modul schaffen, das für alle Änderungen am Datenbestand zuständig sein soll. Das Modul soll als Thread im Hintergrund der Anwendung laufen. Damit ist es zum Beispiel möglich, das während sich der Anwender Bilder anschaut, diese automatisch in der Datenbank aufgenommen werden.  Oder aber das Programm löscht, im Hintergrund, die vom Nutzer markierten Bilder, während er sich schon wieder andere Bilder anschaut.

Nachdem die 3 Etappen erreicht sind, habe ich einen schönen abgeschlossenen Prototypen erreicht, der dann wirklich als Bilddatenbank benützt werden kann.  Vor allem wäre dann der letzte „Testbutton“ aus dem Programm wieder entfernt.

Eine Woche ist mein Urlaub nun schon wieder vorbei und der Arbeitsalltag hat mich wieder eingeholt. Aber eigentlich ist es auch ganz schön so. Jeden Tag unterwegs sein, zwischen Wandern, Shoppen und Spielen, kann schon ziemlich anstrengend sein. Und außerdem geht es mit dem BVASystem ja nur weiter, wenn ich zu Hause bin. :-D

So hab ich nun auch gleich die frohe Botschaft, das aus dem BVASystem nun langsam wieder eine richtige Bildverwaltung wird. Als erste Bildverwaltungsfunktion kann das BVASystem nun die Bilder, die sich in der Datenbank befinden, in einer Baumstruktur darstellen. Vielen Fotografen sollte diese Vorgehensweise bekannt vorkommen. Ich selber habe Jahre lang meine Bilder so auf einer externen Festplatte abgelegt: Ein Ordner fürs Jahr, 12 Unterordner für die Monate und da dann wiederrum bis zu 31 Unterordner für die Tage.

Ok, beim BVASystem es ist noch etwas umständlich, das jedes Bild einzeln in die Datenbank aufgenommen werden muss. Von daher glaube ich nicht, das jemand bereit ist, die Funktion wie sie jetzt ist, groß einzusetzen. Aber dies soll sich in den nächsten Versionen des BVASystems dann ändern. Mit der nächsten Version wird der Verzeichnisbaum dann ebenfalls, wie jetzt der Aufnahmedatumbaum, aus der abstrakten Datenschicht kommen. Anschließend ist es für mich dann die wichtigste Aufgabe, die Bilder möglichst automatisch in die Datenbank aufzunehmen.

Wie im letzten Blogeintrag versprochen, sollte die neue Version (die ab jetzt unter Downloads steht) in der Lage sein, in der Datenbankansicht auch Thumbnails anzuzeigen. Da es schon irgendwie blöde wäre, wenn ich die Thumbnails, wie bei den Bildern von der Festplatte, jedes mal neu erzeugen würde, musste eine neue Datenbankstruktur her.

Die neue Datenbankstruktur liegt wieder als MySQL Workbench Datei nach der Installation in dem Installationsverzeichnis. Am sinnvollsten ist es wohl, wenn die Datenbankstruktur mit dem „Forward Engineer…“ neu erzeugt wird. Ich habe selbst versucht, die Struktur mit dem „Synchronize Modell…“ zu aktualisieren, manchmal klappte es, manchmal ging es erst beim zweiten mal ohne Fehler und manchmal ging es gar nicht. Da die ev. vorhandenen Daten von der neuen Version eh nicht mehr gelesen werden können, ist „Forward Engineer…“ sicherlich die einfachere Variante.

Im Programm selber habe ich die Testfunktion zum Speichern von Bildern in der Datenbank an die neue Datenbankstruktur angepasst. Ebenso habe ich das Laden von Datenbankbildern angepasst und um die vorsprochenen Thumbnails erweitert.

Neue Zoomfaktoranzeige

Da das Wochenende bei mir relativ verregnet war, hatte ich mehr Zeit, um am BVASystem zu programmieren. Um einen relativ alten Eintrag im Bugtracker zu schließen, habe ich mir vorgenommen, dem Nutzer jederzeit Informationen über den aktuellen Zoomfaktor zu geben.  Optisch tat ich mich damit ein wenig schwer, da ich die bisher relativ klare Struktur des Programmes nicht durchbrechen wollte. Herausgekommen ist dabei schlussendlich eine neue Anzeige oberhalb des „großen“ Bildes. Sie setzt sich aus dem Bildnamen und dem aktuellen Zoomfaktor zusammen.

Wieder einmal ist es soweit, das unter Download eine neue Version (2.0.0.4) des BVASystems bereit steht um getestet zu werden. Nachdem in der letzten Version des BVASystems zum ersten mal ein Bild in der MySQL-Datenbank gespeichert werden konnte, ist nicht schwer zu erraten, welche neue Funktionalität ich in den letzten 2 Wochen implementiert habe. Ja, es können sich nun die Bilder aus der Datenbank wieder angeschaut werden.

Ich habe die Datenschicht so erweitert, das es möglich ist, eine Bildliste und das „große“ Einzelbild zu laden. Der Ladevorgang läuft, wie auch bei Bildern von der Festplatte, in gesonderten Threads. Damit ist die Anwendung, auch während ein Bild lädt, weiter bedienbar.

Da der Aufbau der Datenbank noch relativ übersichtlich ist, fehlen bei der Anzeige der Bilder noch einige Funktionalitäten. Zum Beispiel werden in dem Thumbnailstreifen noch keine Thumbnails angezeigt. Auch könnt Ihr noch keinerlei Filter setzten. Es werden immer alle Bilder aus der Datenbank geholt.  Daran möchte ich  in den nächsten Versionen arbeiten. Die „Roadmap“ könnt ihr euch im Bugtracker anschauen.

Nachdem ein guter Freund so nett war, die Version 2.0.0.2 ausführlich zu testen, standen (und stehen auch immernoch) eine Reihe von Bug-Fixes an. Welche der gemeldeten Fehler und Änderungswünsche erledigt wurden, ist dank des Bugtrackers gut nachvollziehbar.

Eine kurze Erklärung werde ich wohl noch zur Datenbank geben müssen. In der Version 2.0.0.3 ist das erste mal im Setup eine Datei enthalten, mit der sich die BVA-Datenbank erzeugen lässt. Ich habe mich dazu entschieden, die Datenbank vorerst als MySQL Workbench Datei weiterzugeben. Mit dem Tool kann die Datenbankstruktur mit jeder neuen Version die ich liefere aktualisiert werden, ohne das die alten Daten gelöscht werden müssen. Die Datei befindet sich nach der Installation im Unterverzeichnis DB des Installationsverzeichnisses.

Wenn die Datenbankstruktur (Wenn man eine Tabelle als Struktur bezeichnen darf.) richtig erstellt wurde, kann mit dem BVASystem das Speichern eines Bildes ausprobiert werden. Für die nächste Version verspreche ich, das die gespeicherten Bilder dann auch wieder angezeigt werden können.

Edith: Jetzt hab ich doch glatt vergessen darauf hinzuweisen das Version 2.0.0.3, wie immer unter Downloads herruntergeladen werden kann. Wünsche also frohes Fehlersuchen ….

Wie versprochen steht nun die erste Datenbankversion zum Download bereit. Allerdings kann die Software sich aktuell nur zur Datenbank verbinden. Es werden keinerlei Tabellen gebraucht, da keine Bilder laden und/oder gespeichert werden. An dieser Stelle möchte ich nun aber kurz erläutern wie man die Verbindung zur Datenbank herstellen kann.

In dem Anwendungsdaten-Verzeichnis (C:\Dokumente und Einstellungen\User\Anwendungsdaten\) befindet sich ein Verzeichnis  „BVASystem“.  Dort liegt eine Ini-Datei „BVASystem.ini“, in der die Parameter für die Datenbankverbindung abgelegt werden müssen. Nach der Installation sehen die Parameter für die Datenbankverbindung wie folgt aus:

[DATENBANK]
PROTOKOLL=
DATENBANK=
HOSTNAME=
NUTZER=
PASSWORT=

Diese 5 Werte müssen beispielsweise wie folgt editiert werden.

[DATENBANK]
PROTOKOLL=mysql-5
DATENBANK=bva
HOSTNAME=localhost
NUTZER=<nutzername>
PASSWORT=<passwort>

Das Protokoll muss zwingend „mysql-5“ sein, da nur für eine Datenbankverbindung zu einer MySQL 5.X Datenbank ein Treiber im Setup integriert ist. Die Datenbank „bva“ muss natürlich vorher eingerichtet worden sein, ebenso der Nutzer und das Passwort.

Wenn alles eingestellt wurde, kann im Programm in der Ansicht „Datenbankbaum“ durch den Button „Test: ConnectDB“  die Verbindung getestet werden.