Hallo zusammen,

trotz meiner Suche bin ich hier nicht auf das Richtige gestossen.

Ich muss mich auf der Arbeit in Delphi einarbeiten und habe dazu Delphi 2010 Professional am Arbeitsplatz.
Ich muss ein Programm erstellen, dass über ComPort/USART auf ein Messgerät, dass wir gebaut haben, zugreift. Eines der Dinge, die das Programm dann können muss, ist das Ablegen der Messparameter, -werte und -ergebnisse in einer Desktop-Datenbank, da es ein mobiles Gerät ist und eine über ein Netzwerk verbundene Datenbank somit ausfällt. Nun bin ich auf der Suche nach einer Desktop-Datenbank, die sich hinterher in den Installer integrieren lässt. Ich habe mich im Internet bereits ein wenig umgetan und von BDE wird einem ja abgeraten. Was gibt es noch für Lösungen? Die Datenbank darf auch gerne eine möglichst kleine Lizenzgebühr kosten, da die Software für das Messgerät separat verkauft wird, denn das Messgerät lässt sich ja auch ohne Software bedienen

Ich hoffe, Ihr könnt mir gute Tipps geben.

Falls eurerseits noch Fragen offen sind, stehe ich Spalier

Vielen Dank und liebe Grüße,
Thomas

spacemanspiff hat folgendes geschrieben :

Nun bin ich auf der Suche nach einer Desktop-Datenbank, die sich hinterher in den Installer integrieren lässt. Ich habe mich im Internet bereits ein wenig umgetan und von BDE wird einem ja abgeraten.

Die BDE ist für deinen Zweck ausreichend denke ich mal (auch wenn sie auf Windows Vista und höher nichtmehr läuft). Alternativ kannst du auch ADO nehmen (die wird glaub ich mit Access installiert), die find ich persönlich aber wirklich schlecht, viel schlechter als die BDE .

Ich kann dir nur SQLite als Stichwort geben, da ich mich dort noch nicht eingearbeitet hab (ich hab es aber vor), aber das müsste ziemlich das sein, was du brauchst.

Hi,

von der BDE wurde ich immer abraten, in deinem Fall aber auch insbesondere, weil sie zu groß ist. Warum solltest du dein Setup um x MB aufblasen, wenn es kleinere lösungen gibt, die für deinen Zweck eben so gut geeignet sind.

Auch mein erster Gedanke war SQLite. Unter Delphi habe ich da noch nicht mit gearbeitet, aber es es auch hierfür tDataset Basierte Komponenten gibt sollte das keine Schwierigkeiten machen.

Wie gesagt mit der BDE würdest du dir nur einen Klotz ans Bein hängen den auch dessen Entwickler schon lange als veraltet und Sackgasse bezeichnet. Die BDE wird nur noch aus Kompatibilitätsgründen für alte Projekte mitgeschleppt, sollte für neue aber nicht mehr genutzt werden.

critter

Hi!

Ich habe seit 12 Jahren beste Erfahrungen mit der TurboDB VCL (Delphi) von DataWeb gemacht. Ich habe z.B. diese portable DB auf einem Stick, neben der EXE liegen. Die Treiber werden automatisch in die EXE einkompiliert. Die DB ist sogar multiuserfähig und auf einen Server später skalierbar wenn nötig. Keine Enduser Lizenzkosten. Ein 100%iger Ersatz für die BDE!

Jome

Wenns Windows sein darf...
Leistungsfähig und einfach Access, Access muss nicht installiert sein, Datenbanken lassen sich auch so generieren und Tabellen/Sichten/Prozeduren per Script einspielen.

Hallo spacemanspiff,

ich würde Firebird benutzen, dafür fallen keine Lizenzkosten an.

Bis bald Chemiker

Hallo,

vielen Dank für die vielen Tipps...

@Xion
BDE kommt nicht in Frage, ich kann ja wohl kaum ein kommerzielles Produkt erstellen, dass auf aktuellen Windows-Versionen nicht läuft
SQLite werde ich mir mal ansehen

@Critter
siehe oben

@jome
Die TurboDB VCL werde ich mir auch mal ansehen, danke schön

@bummi
Werde Access ebenfalls in Betracht ziehen

@Chemiker
Also wenn ich die Lizenzen richtig verstanden habe, darf ich Firebird nicht ohne weiteres in ein kommerzielles Produkt einbinden. Daher werde ich davon absehen. Aber ich habe noch InterBase zur Verfügung, vielleicht schaue ich da auch mal rein


Alles in allem habe ich jetzt erst mal einige Vorschläge, so dass ich mir die genannten Datenbanken detaillierter ansehen muss. Kennt Ihr für SQLite, TurboDB VCL, Access, InterBase gute Delphi-Tutorials? Bisher habe ich Datenbanken immer per Hand eingebunden, aber Delphi macht so viel im Hintergrund und bietet so viele Parameter, dass einem fast schwindelig werden könnte.

Vielen Dank und liebe Grüße,
Thomas

bei Access brauchst Du nur eine ADOConnection (serverseitig) und die entsprechenden ADODatasets.

Hi,

spacemanspiff hat folgendes geschrieben :

@Chemiker Also wenn ich die Lizenzen richtig verstanden habe, darf ich Firebird nicht ohne weiteres in ein kommerzielles Produkt einbinden. Daher werde ich davon absehen. Aber ich habe noch InterBase zur Verfügung, vielleicht schaue ich da auch mal rein

also da habe ich bei Firebird noch nie von Problemen gehört und ich kenne einige Kommerzielle Projekte, die das benutzen. Das einzige was du meines wissen nicht darfst (wie bei Open-Source üblich) ist es FireBird selbst zu verändern und es dann als kommerzielles DBMS verkaufen.

Bei FireBird sehr nett ist die Möglichkeit zwischen Embedded und "großem" Server um zu schalten. In der Embedded Variante lieferst du nur eine (oder wenige?) DLLs aus und wenn du dann einmal in einer Installation einen echten Server brauchst, weil z. B. von vielen Netzwerkarbeitsplätzen drauf zugegriffen werden soll, dann kannst du diesen installieren und ohne nennenswerte Programmänderungen darauf umstellen (wenn du es richtig machst dürfte es reichen die Zugriffspfade in einer deiner INIs zu ändern)

Es sollte also auch einen Blick wert sein, wenn das für dein Projekt nicht schon wieder zu oversized ist.

bummi hat folgendes geschrieben :

Wenns Windows sein darf... Leistungsfähig und einfach Access, Access muss nicht installiert sein, Datenbanken lassen sich auch so generieren und Tabellen/Sichten/Prozeduren per Script einspielen.

Das ist nicht ganz richtig. Bei neueren Windows Versionen muss nichts installiert werden, da MDAC Teil des Betriebsystems ist. Bei Systemen ich glaube vor XP (oder auch noch bei XPs ohne Servicepack?) muss es erst installiert werden.
Als besonders Leistungsfähig habe ich Access aber nicht kennengelernt. Im Gegenteil es schien mir bei größeren Datenmengen oder größerem alter eher recht träge zu werden. Daher würde ich persönlich es nur bei kleinen Projekten einsetzen, mit der Stabilität hatte ich aber in der tat nie Probleme (ganz im Gegensatz zu dem ganzen BDE gedöhnz).

critter

Hallo,

Firebird ist eine freie DB, Beschränkungen betreffen eigentlich nur den Quellcode von Firebird selber.

Bis bald Chemiker

Hi,

also jetzt habe ich erst mal ein wenig zu tun. Habe mit FireBird, SQLite, TurboDB und zusätzlich AbsoluteDB mal besorgt und werde mal ein wenig damit herum spielen.

Vielen Dank für Eure Unterstützung

Gruß,
Thomas

spacemanspiff hat folgendes geschrieben :

Ich muss mich auf der Arbeit in Delphi einarbeiten und habe dazu Delphi 2010 Professional am Arbeitsplatz. Ich muss ein Programm erstellen, dass über ComPort/USART auf ein Messgerät, dass wir gebaut haben, zugreift. Eines der Dinge, die das Programm dann können muss, ist das Ablegen der Messparameter, -werte und -ergebnisse in einer Desktop-Datenbank

Kleine Warnung am Rande: Wenn Du Pech hast, laufen die Daten so schnell ein, dass die Datenbank mit dem Wegschreiben nicht mehr nachkommt, insbesondere, wenn die Datei auf einem Netzwerklaufwerk liegt. Das haengt natuerlich von der Datenrate auf der seriellen Schnittstelle und den Latzenzeiten des Netzwerks ab.

Wir cachen die Daten deshalb, waehrend die Messung laeuft, in einer lokalen Datei und schreiben sie erst nach Abschluss in eine Datenbank.

twm

Hi dummzeuch,

also da machen wir uns momentan noch nicht so große Sorgen drum. Es kommt jede Sekunde ein einzelner Messwert plus Zeit und Status, so dass wir auf 7 Bytes pro Sekunde kommen. Davon werden aber nur 2 Byte in einem Array verwahrt. Insgesamt fallen maximal 2048 Bytes pro Messung an, die wir alle in einem Byte-Array sammeln. Nach dem Ende der Messung erfolgt noch eine Berechnung und dann erst werden die Dateien in einer Datei und der Datenbank gesichert. Denke, das wird einigermaßen problemlos sein. Vor allem, weil dann bis zum Start der nächsten Messung mindestens 150 Sekunden verstreichen.

Danke trotzdem für den Hinweis!

Beste Grüße,
Thomas

so wie sich das hier anhoert, ist sqlite genau das richtige für dich. schau dir mal die zeos lib an. ist ein interface für etliche datenbanksysteme.

gruss
tankard

Wie gesagt habe ich mir einige Datenbanken heraus gesucht und teste jetzt mal damit herum.

Vielen Dank für Eure Beiträge

Gruß,
Thomas

Frage: Bei Messwerten handelt es sich doch eigentlich nur um einen oder mehrere Messwerte, die pro Abrufung des Messgerätes gespeichert werden. Möglicherweise ein Parameter, welcher die Messzeit beinhaltet und dann irgenwelche Messwerte (Spannung, pH-Wert, Strom, Temperatur ...). Oder sehe ich das verkehrt?

Was passiert mit der Datenbank? Werden dort nur die Messwerte verwaltet oder gar weiterverarbeitet?
Vielleicht ist das Ablegen in eine einfache Textdatei völlig ausreichend. Die meisten Messgeräte, welche ich kenne, erzeugen eine Textdatei. Die kann man dann in Excel einlesen und die Messwerte dann weiter verarbeiten.

Das ist z.B. eine sehr problemlose und einfache Datenverwaltung.

Nur ein Vorschlag. Dazu benötigst Du keine weiteren Programme.

Statt einer selbstgestrickten Datei und den dann selbst zu programmierenden Zugriffen auf die Daten könnte man ein ClientDataSet nutzen. Mit Hilfe der .SaveToFile bzw. .LoadFromFile -Methoden kann man den Inhalt als Datei speichern, zur Laufzeit das Clientdataset aber wie eine Datenbanktabelle benutzen (sprich Filtern, Append, Delete, Anzeige mit DBGrid u.ä.). und falls man dann irgendwo die Daten in eine echte DB speichern muss, baut man eine 'speichereInDb' - Methode, und schon hat man DB-Funktionalität ohne DB-Installations-/Pflegeaufwand.
Nur mal so als Tipp bzw. evtl. Alternative.

Hi Tranx,

unser Messsystem liest einen Detektor, um Inhaltsstoffe von Gasen zu ermitteln. Die längste Messreihe läuft 720 Sekunden und sammelt 1440 Bytes, der Rest ist Header (Messort, Datum, Uhrzeit, etc.). Die komplette Messreihe muss gespeichert werden, falls ein Nachweis beigebracht werden muss, dass Stoff XY mit einem Gehalt von mindestens XY mg enthalten ist. Im Messsystem haben wir eine SD-Karte, auf der die Dateien abgelegt werden. In der Regel läuft alle 20 Minuten eine automatische Messung, so dass 72 Dateien pro Tag anfallen.
In der Regel steht das System irgendwo rum und misst fröhlich vor sich hin, allerdings gibt es auch Anwender, die das mobil transportieren.
Das Programm muss nun zweierlei können:

1.
Über UART das System erkennen und Informationen austauschen können (grob: Messung starten und Messung "belauschen"). Messkurve, Detektorwerte, etc. auf dem Laptop darstellen, usw.

2.
Importieren der gesammelten Textdateien von den stationären Geräten und Analysemöglichkeiten (verschiedene Kurven eines oder mehrerer Geräte, verschiedene Zeiträume, etc.)

Am wichtigsten sind die Analysemöglichkeiten.

@zuma
Die eigene Datenbank bietet sich an, denn wenn der Anwender sagt "zeige Messkurve der letzten 6 Monate der Standorte A, B und C" will ich lieber eine Datenbank durchforsten, als Hand an tausende Textfiles legen zu müssen

Gruß,
Thomas

da hast du mich falsch verstanden bzw. ich mich wohl unverständlich ausgedrückt.
Du speicherst immer nur 1 Datei mit allen Daten.
also nur eine Datei einlesen und dann z.b. Filtern ('Standort = a and Standort = c and Erfasszeit > einDatum' oder so ähnlich)
TClientdatasets sind die Datenbank, die man nich hat