MS Access Anbindung

Hallo!
Ich muss für Protokollzwecke mehrere Daten auf einmal in eine Access-Datenbank schreiben.
Die Tabelle ist ziemlich lang und es kommt mir so vor, als ob sie für die ADO-Tools sogar zu lang ist. Es sind 54 Spalten.
Kann das damit zusammenhängen?

  write_to_access.vi (Größe: 17,71 KB / Downloads: 317)


  read_from_ini_subvi_.vi (Größe: 15,05 KB / Downloads: 248)


  Firestar_Protokoll_list.txt (Größe: 823 Bytes / Downloads: 308)


  Laufende_Protokollierung.zip (Größe: 389,77 KB / Downloads: 242)

Die erste Datei ist jene mit der nach Access geschrieben werden sollte.
Die zweite ist ein SubVI des ersten.
Die txt-Datei wird von "write_to_access" benötigt.
Das 4. Attachment ist die Access-Datenbank.

Ich verwende LabVIEW-Version8.6.

lg Florian

Anzeige

Ich kenne das ADO-Toolkit nicht, da ich das NI-Database-Connectivity-Toolkit habe und da hatte ich bis jetzt keine Probleme, wobei ich aber auch keine Tabellen mit 54 Spalten habe.
Außerdem übergebe ich immer nur Parameter an eine DB-Funktion und führe die ganzen Befehle (INSERT,...) auf Datenbankebene durch.
Das geht aber meines Wissens nach mit Access noch nicht (ich verwende eine PostgreSQL-DB).
Ich denke, dass Dir in dem Fall aber "i2dx" weiterhelfen kann.

Gruß Markus

nein, die Anzahl der Spalten ist kein Problem. Da du das SQL-Statement von Hand zusammenbaust (was auch gut so ist) kannst du so viele Spalten angeben wie du möchtest (sofern die auch in der DB vorhanden sind)

Ich vermute da ist irgendwo ein Fehler im SQL-Statement. Der Fehler kommt auch zurück (in Error Out) den müsstest du mal analysieren. Ein Trick um SQL-Statements zu debuggen ist auch: ein Anzeige-Element einzubinden, dass dir das fertige Statement anzeigt, das du abschickst - das kannst du dann ggf. noch rauskopieren und in Access direkt mal abschicken, die Fehlermeldung dort dann doch deutlich schöner formatiert und man sieht den Fehler einfach schneller ...

Welche Fehlermeldung bekommst du denn wenn du das Statement abschickst?

Erstmals vielen Dank für die Antworten!

Das mit dem Debuggen hab ich auch gemacht. Das SQL-Statement war eigentlich in Ordnung.

Die Fehlermeldungen haben nur einen Syntaxfehler gemeldet, also ziemlich allgemein.

Auf die Idee mit den zu vielen Spalten bin ich gekommen, weil es mit weniger Elementen tadellos funktioniert hat.
Bei näherer Betrachtung bin ich aber draufgekommen, dass einige Spalten Leerzeichen und Sonderzeichen beinhalten. Damit hat jetzt entweder ADO oder SQL ein Problem gehabt. Access jedenfalls nicht. Ich hab die Spalten nun umbenannt und es funktioniert tadellos.

lg Florian

' schrieb:Auf die Idee mit den zu vielen Spalten bin ich gekommen, weil es mit weniger Elementen tadellos funktioniert hat.
Bei näherer Betrachtung bin ich aber draufgekommen, dass einige Spalten Leerzeichen und Sonderzeichen beinhalten. Damit hat jetzt entweder ADO oder SQL ein Problem gehabt. Access jedenfalls nicht. Ich hab die Spalten nun umbenannt und es funktioniert tadellos.

Andere Variante nächstes Mal ist um die Spaltennamen die ein Leerzeichen enthalten (geht aber auch wenn sie keine Leerzeichen enthalten) in eckigen [] Klammern schreiben. Das gibt dem SQL Parser an, den ganzen Ausdruck als einen Identifier zu interpretieren statt jedes einzelne Wort. Die meisten mehr professionelen Datenbanken sind nicht so übereifrig wie Access und bestehen auf diesen eckigen Klammern für Namen die ein Leerzeichen enthalten.

Aber die Idee um Leerzeichen zu vermeiden ist natürlich noch beinahe besser.

Rolf Kalbermatter

Mein Tip: Um irgendwelche Probleme zu umgehen verwende ich als Spaltenbezeichnung nur klein-, und zusammengeschriebene Wörter ohne Sonderzeichen. Ich verwende PostgreSQL und hatte seither keine Probleme mehr.

Gruß Markus

' schrieb:Andere Variante nächstes Mal ist um die Spaltennamen die ein Leerzeichen enthalten (geht aber auch wenn sie keine Leerzeichen enthalten) in eckigen [] Klammern schreiben. Das gibt dem SQL Parser an, den ganzen Ausdruck als einen Identifier zu interpretieren statt jedes einzelne Wort. Die meisten mehr professionelen Datenbanken sind nicht so übereifrig wie Access und bestehen auf diesen eckigen Klammern für Namen die ein Leerzeichen enthalten.

Aber die Idee um Leerzeichen zu vermeiden ist natürlich noch beinahe besser.

Rolf Kalbermatter

' schrieb:Andere Variante nächstes Mal ist um die Spaltennamen die ein Leerzeichen enthalten (geht aber auch wenn sie keine Leerzeichen enthalten) in eckigen [] Klammern schreiben. Das gibt dem SQL Parser an, den ganzen Ausdruck als einen Identifier zu interpretieren statt jedes einzelne Wort. Die meisten mehr professionelen Datenbanken sind nicht so übereifrig wie Access und bestehen auf diesen eckigen Klammern für Namen die ein Leerzeichen enthalten

Danke für diesen Tipp!

Die Namen wurden von mir und einem Kollegen deshalb so gewählt, weil wir dann die gleichen Bezeichnungen wie beim Anzeigen während des Programmablaufs verwenden hätten können. So könten wir den gleichen String für das Schreiben in die Datenbank als auch fürs Anzeigen an der Benuterzoberfläche verwenden (klingt jetzt vielleicht ein bisschen unverständlich, aber wenn man das Projekt näher kennt klingts logisch).

Ich glaube aber, dass ich die Spaltennamen jetzt umbenenne und habe mir schon eine Funktion ausgedacht, um unser entstandenes Problem zu lösen.

Danke!

lg FLorian