Einzelnen Beitrag anzeigen

Benutzerbild von trifid
trifid

Registriert seit: 12. Sep 2003
297 Beiträge
 
#15

Re: Messdaten in DB speichern

  Alt 25. Nov 2005, 08:27
Hallo,

ich würde folgenden Varinate vorschlagen
verwende ein TObjectList - das Item enthält die Messdatenstruktur (Datum, Zeit, Messnummer, Messwert1, Messwert2, etc.)
(das geht schnell und man kann es auch threadsicher programmieren)
(oder doch eine TStringListe - da musst du mal Zeitmessungen machen)
Nach dem Mess-Ende diese Liste in einen File ablegen
Anschließend die Datei über einem "bulk copy" in die MSDE reinladen mit dem Tool bcp.exe
(das geht auch wieder fix, wenn die Dateistruktur gleich der Tabellenstruktur ist)

Wenn du Multithreading verwendest möchtest , könntest du beides gleichzeitig anwenden und "nonstop" Messreihen fahren
1ter Thread nimmt Messung auf und legt die Daten in die TObjectList/TStringList
2ter Thread verwaltet die Messreihen und erzeugt in 1000er oder 10000er die Datei
3ter Thread verwaltet das Löschen der Objectlist bereits übertragener Daten (dafür brauchst du ein Löschkennzeichen im Item)
4ter Thread führt den "bulk copy" durch

Ich würde mich nicht mit ADO oder der MSAccess abgeben (weil die Schnittstelle zu langsam ist), eher würde ich
eine DBase (.dbf) Datei verwenden wo gleich die Messdaten reingeschrieben werden
(weil dies einfach mit DBase schneller geht)
( nicht über die BDE ((da ist auch zuviel zwischen drin)) eher http://sourceforge.net/projects/tdbf)
(nebenbei, viele Industrieschnittstellen verwenden DBase als Datenbankaustauschformat, weil es einfach, schnell und netzwerktauglich ist)
wenn's mit "ADS Advantage Local Server" geht, soll es genau so gut sein (wichtig ist, das die Abtastung von 8ms erhalten bleibt)
Anschließend die Daten in einen SQL-Server deiner Wahl importieren - für eine komfortable und schnelle Auswertungsmöglichkeit

Einen Ringbuffer wie hier vorgeschlagen würde ich nicht empfehlen, da du nie weißt ob die Daten überrollt werden
Außerdem ist die Verwaltung von einem Ringbuffer auch nicht ganz ohne - wenn gleichzeitig 2 Prozesse lesend oder schreiben darauf zugreifen
Eine eigene Datenbank macht wenig sinn, weil es genügend Alternativen für dein Problem gibt
  Mit Zitat antworten Zitat