Hallo,
Wenn ich im MySQL Query Browser
DELETE FROM tab1.sieb WHERE (SiebNummer = 2 ) AND (Zeitpunkt < "2008-05-12 12:07:20");
eingebe sind die alten Daten, wie gewünscht weg (österreichisch: "futsch").
Wie sag ich es meinem LabVIEW? So einfach wie in meinem Versuch geht das aber nicht.... Bitte um einen Tipp
Danke
Gottfried
Hallo,
durch herumprobieren die Lösung:
nach dem "Execute Query" braucht es ein "Free Object"...... das ist so offensichtlich klar, logisch und intuitiv das man es nirgends erwähnen muss. Ich bin hingerissen.
Was ich mich ernsthaft frage (ich schreibe selber manchmal Manuals) baut man selber auch so einen Scheiss? Wahrscheinlich - man sieht die Probleme eines "externen" nicht.....
OK - es hat viel Zeit gekostet aber es pfeifft
Gottfried
' schrieb:Hallo,
durch herumprobieren die Lösung:
nach dem "Execute Query" braucht es ein "Free Object"...... das ist so offensichtlich klar, logisch und intuitiv das man es nirgends erwähnen muss. Ich bin hingerissen.
Was ich mich ernsthaft frage (ich schreibe selber manchmal Manuals) baut man selber auch so einen Scheiss? Wahrscheinlich - man sieht die Probleme eines "externen" nicht.....
OK - es hat viel Zeit gekostet aber es pfeifft
Gottfried
Wahrscheinlich hast Du defaultmässig Command Tranaction oder wie das wohl genannt wird enabled. Dann wird jede Command Connection als Transaction behandelt die erst mit dem Abschliessen des Commands endgültig in die Datenbank übernpmmen wird. Wenn Dir die Applikation dann mitten in einem komplexen Update oder Delete abschmiert ist die Datenbank noch stets in einem konsistenten Zustand.
Zur Dokumentation, sowas ist Datenbank spezifisch und das im DB Toolkit zu dokumentieren würde ins absolut Uferlose ausarten da Du nicht erwarten kannst dass jemand für Dich das Toolkit in jeder möglichen Datenbank testen kann und alles was damit zusammenhängt dokumentieren wird.
Anstelle des Abschliessen des Commands sollte auch ein explizites Commit möglich sein. Ob durch eine vorgefertigte Routine des DB Toolkits, oder durch eine nicht im DB Toolkit benützte Methode der ADO, oder gar durch ein entsprechendes SQL Statement wird wohl auch wieder Datenbank spezifisch sein.
Rolf Kalbermatter
Hallo,
Command Tranaction: ist eben auf die schnelle NICHT im Help ersichlich
Datenbank spezifisch: die (meine) Abfrage via ODBC sind im Kern Standard - was ich brauchte war auch nicht Dialekt sondern mehr als primitiv.
Faktum ist die schwache Ader die NationalInstruments in der Doku abliefert. LV ist toll aber eine Programmiersprache die von der Überlieferung (wie hier im Forum) und externen Dokumenten lebt - und gut lebt. LV ist wirklich super, aber man wird ja noch auf diese Schwachstelle hinweisen dürfen.
Vielen Dank
Gottfried
' schrieb:Hallo,
Command Tranaction: ist eben auf die schnelle NICHT im Help ersichlich
Datenbank spezifisch: die (meine) Abfrage via ODBC sind im Kern Standard - was ich brauchte war auch nicht Dialekt sondern mehr als primitiv.
Ob Session Transaction default ansteht oder nicht oder gar überhaupt nicht unterstützt wird hängt ausschliesslich von der Datenbank und eventuel dem Datenbanktreiber ab. Die entsprechende Einstellung dazu kann manchmal in der Treiberkonfiguration gemacht werden ist aber oft auch einfach eine Einstellung die in der Datenbank selber gemacht wird und selbst vom Treiber ganz unabhängig ist.
Wenn Du hierzu über eine Dokumentation meckern willst musst Du dies schon über die Dokumentation zu Deiner Datenbank oder eventuel dem verwendeten Datenbank ODBC/ADO Treiber tun. Aber wahrscheinlich steht das da sogar ganz einfach drin. Wer liest denn schliesslich 1000 Seiten Dokumentation bevor er mit dem Programmieren beginnt?
Selber habe ich noch nie mit MySQL gearbeitet aber von dem was ich gehört habe ist die Dokumentation recht gut aber auch enorm umfangreich und nicht immer so gewaltig strukturiert. Vom Community Support für MySQL habe ich allerdings noch nicht soviel Gutes gehört.
Im Hinblick auf Session Transaction Support hat das Database Toolkit normalerweise keinerlei Kenntnis davon. Du kannst allerdings mittels dem Database Toolkit selbst Transactions explizit programmieren und das ist dann schon dokumentiert.
Danksei ODBC, resp. ADO hat mein ein universelles Programmierinterface zu fast allen Datenbanken aber wie die jeweilige Datenbank bestimmte Dinge dann genau implementiert oder nicht ist noch immer eine riesige Herausforderung. Mit ODBC wurde mal propagiert dass man nun Datenbanken fast wie in Plug and Play beliebig austauschen kann ohne dass an einer Applikation auch nur etwas geändert werden muss. In der Praxis ist es noch immer sehr weit davon entfernt, ausser man hält sich sehr strikt an den grössten gemeinsamen Teiler aller gewünschten Datenbanken, aber das alles auszusuchen kostet meist noch mehr Zeit dann es bei Bedarf mit einer neuen Datenbank Engine zu testen und anzupassen.
Rolf Kalbermatter