LabVIEWForum.de

Hallo LVF,

wir sollen hier für nen Kunden einen Prüfautomat bauen. Es werden dabei innerhalb eines Prüfzyklus (ca. 30 Schaltungen) das Minimum und Maximum von zwei Messwerten erfasst. Diese beiden Werte sollen am Ende der Prüfung zusammen mit einigen Benutzerdaten (Produktnummer, Benutzer, Datum, etc.) gespeichert werden. So weit so gut...

Die Anforderung im Lastenheft lautet: "Die Ergebnisdatensätze sollen im SQL-Format vorliegen." Zusätzlich kam vom Kunde noch die mündliche Aussage "Naja die Ergebnisse sollen halt mit SQL-Befehlen abrufbar sein!"...

Jetzt stellt sich für mich die Frage: Wie mach ich das? Habt ihr irgendwelche Vorschläge und/oder Tipps, wie diese recht allgemeine Anforderung mit den geringsten Schmerzen umzusetzen ist? Welche DB-Variante bietet sich an bzw. mit welchen habt ihr schon gute oder schlechte Erfahrungen gemacht?

Ich freue mich auf euren Input!

Gruß
Achim

Hi Achim,

ich verwende die Freeware-DB PostgreSQL in Verbindung mit dem Database Connectivity Toolkit von NI und habe bisher nur gute Erfahrungen damit gemacht, weil ich dort auch die Hauptfunktionalität auf Datenbankebene machen kann, d.h. ich übergebe von LabVIEW nur Werte an eine Funktion und die Werte werden dann auf Datenbankseite verarbeitet.

Gruß Markus

Hallo Achim

ich benutze zur reinen Messdaten Ablage MySQL mit dem ADO-Tool hatte damit bisher auch noch keine Probleme ...

Wenn der Kunde die Ergebnisse mit SQL Befehlen abrufen will hatt er evtl schon eine DB Lösung... dann würd ich darauf aufbauen.. da muss der Kunde nix neues benutzen lernen ...

weiter fällt mir nur noch ne Access DB ein .. aber damit hab ich keine Erfahrung ...(will ich auch nicht unbedingt)

Toaran

' schrieb:Die Anforderung im Lastenheft lautet: "Die Ergebnisdatensätze sollen im SQL-Format vorliegen." Zusätzlich kam vom Kunde noch die mündliche Aussage "Naja die Ergebnisse sollen halt mit SQL-Befehlen abrufbar sein!"...

Willst du echt meine Meinugn hören? Auch wenn nicht:

Die Aussage "Die Ergebnisdatensätze sollen im SQL-Format vorliegen." ist völlig irrelevant. Datensätze liegen nicht im SQL-Format vor, sondern die DB, in denen die Ergebnisdatensätze gespeichert werden soll, muss mit SQL-Statements managebar sein. Mündliche Aussagen, wie die, die der Kunde berichtigenderweise gemacht hat, zählen nicht. Somit ist die Lastenheft-Ausage dehnbar bis ins unendliche.

Ich soll gerade eine Oracle-DB ansprechen. Vom MS-Oracle-Treiber raten alle (auch nicht-LV-Benutzer) ab, obwohl man mit dem alle Tabellennamen auslesen kann. Den Original-Oracle-Treiber soll ich nehmen - der liest aber die Tabellenname nicht aus. Soviel zum Zusammenspiel LV - Oracle-DB. Auf LV-Seite verwende ich das Database Connectivity Toolkit.

Meine Meinung:
Die DB soll der Kunde bereit stellen. Auch müssen bereits alle benötigten Tabellen konfiguriert sein. Wenn der das nicht will, nimmst du das einfachste was du finden kannst. Machs, wie Y-P geschrieben hat.

Hallo,

ich verwende MySQL für den Kunden: ist eine billige Schnittstelle und es gibt viel Wissen darüber. Bin (wenigen mit Ausnahmen) auch mit dem DB-Toolset zufrieden (dem alten) das neue (vor 1 Woche auf meinem Schreibtisch gelandet) habe ich noch nicht verwendet.

Gottfried

PS.: man darf aber nur den ODBC Driver 3.51 verwenden

' schrieb:Jetzt stellt sich für mich die Frage: Wie mach ich das? Habt ihr irgendwelche Vorschläge und/oder Tipps, wie diese recht allgemeine Anforderung mit den geringsten Schmerzen umzusetzen ist? Welche DB-Variante bietet sich an bzw. mit welchen habt ihr schon gute oder schlechte Erfahrungen gemacht?

meine Empfehlung:

ADO-Toolkit und Access

Ich würde auch auf Access setzen, für die paar Tabellen und Verknüpfungen.

Hat den Vorteil (für dich),
- dass es meistens bereits gekauft/installiert haben.
- die Anwender Freude haben, dass sie nun mal neben Excel, Word und Outlook auch für Access einen Verwendungszweck haben.
- kann von der "normalen" Informatik/Administration gewartet werden.

' schrieb:Ich würde auch auf Access setzen, für die paar Tabellen und Verknüpfungen.

Hat den Vorteil (für dich),
- dass es meistens bereits gekauft/installiert haben.
- die Anwender Freude haben, dass sie nun mal neben Excel, Word und Outlook auch für Access einen Verwendungszweck haben.
- kann von der "normalen" Informatik/Administration gewartet werden.

du musst Access nicht installieren um die Datenbank verwenden zu können. Access ist nur ein Frontend für die JET-Database-Engine, die mit dem Microsoft Data Access Components installiert wird. Die JET DB-Engine ist auf jedem Rechner mit Windows 2k pro oder höher bereits installiert. Falls das aus irgend einem Grund nicht vorinstalliert sein sollte, kann man sich die MDAC kostenlos von Microsoft runterladen und nachinstallieren.

der ganz große Vorteil von Access / Jet + LabVIEW ist: man muss einfach nur eine Datei (die *.mdb-Datei) mit auf das Ziel System kopieren und hat dort sofort die DB-Anbindung. In meinem ADO-Toolkit ist dieser Umstand auch in besonders einfacher Weise berücksichtigt: mann muss einfach nur den Pfad zur Access-Datei angeben, alles andere ist schon erledigt, kein UDL, kein Connection Strind oder was auch immer, einfach nur c:messdatenmessdaten.mdb reicht

die Software "Access" braucht man nur um die Datenbank zu entwerfen und z.B. um sich dann die Daten anzuschauen, Berichte usw zu erstellen, aber NICHT um z.B. aus LV heraus Daten in einer Access-DB (*.mdb-File) zu speichern!.

Der Vorteil, dass man nur eine Datei kopieren muss macht das ganze unter anderem auch sehr komfortabel, wenn man einen Installer bauen will, der auf mehreren Rechnern installiert wird. Mein IBB-Logger funktioniert auch so

Bei MySQL, MSSQL Express, etc hat man immer das Problem, dass man noch einen Datenbank-Server einrichten und zumindest grundlegend administrieren muss, und das ist schon etwas mehr Aufwand als einfach nur eine Datei zu kopieren.

Darum lautet meine Empfehlung nochmal ganz explizit:
da die Datenstruktur SEHR einfach ist und es nur darum geht die Daten in einer Datei abzulegen, die per SQL-Queries abfragbar ist: ADO-Toolkit + Access Datenbank

eine Access Datenbank kann eine maximale Größe von 2 GB haben, und in einer Tabelle (mit einem numerischen Schlüssel --> i32 ) kann man über 2 E9 Zeilen in eine Tabelle speichern, das sollte für diese Aufgabe auf jeden Fall ausreichen. Der Export nach Excel oder auch nach DIADem gestaltet sich sehr einfach (Stichwort: Menü-->Extras-->externe Daten importieren)

Den Aufwand mit MySQL oder MSSQL-Server treibe ich nur, wenn ich entweder kompexe Abfragen benötige, die ich in Stored Procedures unterbringe oder wenn die Datenbank bzw. die Verknüpfungen komplexer sind.

Das ist aber wirklich interessant

Danke

Gottfried

Hallo,

nur als Nebenbeianmerkung: Bei den ganzen Überlegungen hier werden Aspekte zur Plattform - also dem Betriebssystem - nie betrachtet, sondern es wird immer davon ausgegangen, dass Windows verwendet wird.

Eines der wenigen echten Features von LV ist aber doch Plattformunabhängigkeit. Eine Option, die durch die Verwendung von ADO (möglichst noch im Zusammenspiel mit Access) leichtferig verspielt wird.

Ich find es erstaunlich.

meine zwei Cent
t4b-1re-2