Hallo zusammen,

ich sitze gerade einem VB-Programm, dass Daten aus .csv-Dateien ausliest und sie letztlich in eine mySQL-Datenbank schreiben soll. Als ziemlicher Anfänger habe ich mir in Tutorials und auf connectionstrings.com angeschaut, wie man über VB so eine Verbindung herstellt, habe mir den MySQL Connector net besorgt und den Verweis gesetzt, aber es will nicht klappen und ich bin mit meinen paar Brocken Latein am Ende.

Ausschnitt aus dem Code:



Den SQL-Befehl habe ich mir schon per Debug.Print ausgeben lassen und im Query Browser getestet, der ist in Ordnung.
Ich bekomme auch keinen lesenden Zugriff. Ich hatte die DB mit einem Testdatensatz gefüllt, den ich über .ExecuteReader auslesen und in einer Listbox anzeigen lassen wollte. Da kam die Fehlermeldung "Connection must be valid and open". Scheint also ganz so, als käme einfach keine Verbindung zustande.

Was mache ich falsch?

Danke,
uHu.

wo wird in diesem Code der query ausgeführt?
sieh dir dazu mal openbook.galileocomputing.de/e…d84dda1a76ca30b61f063fd39 <-- das an

hier wird es zwar mit einer Access DB gemacht aber das Prinzip ist das selbe.

lg

Danke, das habe ich schon offen

Der Haken ist, wenn ich ein cmd.Execute mache, kommt besagter Fehler: "Connection must be valid and open"

wo machst du den execute?

dieser muss zw. den Codezeilen con.Open() und con.Close() passieren.
con.Close() schließt die Verbindung wieder.

wenn du das so probierst:
mit dem einem Button öffnest du die Verbindung und mit einem anderen führst du den Query aus wird das so nicht funktionieren.

passe den Code aus dem Link mal genau so an wie es beschrieben ist. Darunter fällt auch, dass du das in einen Try-Catch Block wirfst da sonst eine Exception geworfen wird wenn der Connect nicht passt.

Danke für Deine Hilfe,

es klappt jetzt. Der Try-Catch-Block hat mich langsam herangeführt. Ich hatte den ConnectionString innerhalb einer Schleife stehen und das hat beim nächsten Durchlauf immer die Exception geworfen.

uHu schrieb:

Der Try-Catch-Block hat mich langsam herangeführt.

Nanu?

Normalerweise führt ein TryCatch eher weg vom Fehler. Ohne TryCatch stößt die IDE dich direkt auf die Fehlerzeile, aber der TryCatch catcht die Fehlermeldung erstmal weg.
Bei Galileo wird sie dann in einer Messagebox ausgegeben - das kann die IDE aber selber besser.
Nämlich die markiert genau die Fehlerzeile, und du kannst alle Variablen im Lokal-Fenster überprüfen.

gugge AvoidTryCatch

ErfinderDesRades schrieb:

gugge AvoidTryCatch

Ich finde so sagen kann man es nicht... Mir ist es lieber wenn ich mein Programm Kontrolliert abschießen kann, ggf. noch Speicher freigeben usw. (Ich weiß GarbageControl usw.. aber trotzdem, sicher ist sicher, kommt auch ein bisschen aus der Programmierung ohne GC:D) Ich denke das Abfangen von Fehlern ist immer gut, klar bekommt man nicht mehr die genaue Zeile usw.. Aber ein guter Programmierer sollte aus der Fehlermeldung "herausfiltern" können wo sich ein Fehler eingeschlichen hat.

lg.

LucaWelker

LucaWelker schrieb:

Mir ist es lieber wenn ich mein Programm Kontrolliert abschießen kann,...

Was ist unkontrolliert an einem Programm-Abbruch aufgrund einer Exception?
Das ist eine der besten Kontrollen, die im Falle einer Exception überhaupt noch möglich sind.

Vor allem: Siehst du im Galileo-Code überhaupt eine Zeile, die das Programm kontrolliert beendet? Ich nämlich auch nicht.
Das bedeutet: Die Anwendung läuft unkontrolliert weiter.

Das ist einer der Punkte, warum ich das Galileo-Book bestenfalls für mäßig halte: Diese TryCatchens werden reihenweise von Anfängern in ihre Apps übernommen, und reihenweise laufen Anwendungen weiter, obwohl Datenzugriffe fehlgeschlagen sind.
Das ist der erste Schritt in den absolutely worst case einer Produktiv-Anwendung: jetzt braucht die App nur noch die Nichtgeladenen Daten zurückzuspeichern, und der Original-Datenbestand ist futsch.

Ich denke das Abfangen von Fehlern ist immer gut...

Nein, es ist fast nie gut.
Grundsatz ist: Fange nur Exceptions, die du auch behandeln kannst. Und das ist fast nie der Fall - wie soll denn eine Anwendung weiterlaufen, wenn der Datenzugriff fehlschlägt?

Aber ein guter Programmierer sollte aus der Fehlermeldung "herausfiltern" können wo sich ein Fehler eingeschlichen hat.

Sicher kannerdas. Aber ein besserer Programmierer delegiert dieses "herausfiltern" an die IDE, die kanns nämlich noch besser (wenn man sie läßt).

ErfinderDesRades schrieb:

Was ist unkontrolliert an einem Programm-Abbruch aufgrund einer Exception?

Meines Wissens ist das in C# kein Thema, da hast recht.. Aber in C++ kann es Problematisch werden wenn du anfängst dinge im Heap abzulegen und dein Programm 100 mal gestartet wird und 100 mal abstürzt und bei jedem Start legst du 2 arrays a 2000 Elemente an, dann läuft i.wann der arbeitsspeicher voll.. Ich hab mir mal en Programm geschrieben in c++ bzw. 2 Zeilen code:D welche mir in einer while(true) (dauerschleife) arrays mit 5000 Elemnten leer anlegt und nichts damit macht.. 5 Sekunden war der Arbeitsspeicher voll. Noch aber konnte man das Programm kontrolliert schließen dann war alles wieder weg. Wenn ich aber einmal durch null geteilt habe(um nen Fehler zu verursachen) ohne try catch ausenrum und das Programm ist mir Abgeschmiert, war der arbeitsspeicher weiterhin gleich voll. Und ich musste den Rechner neustartet.

lg.

LucaWelker

If teiler <> 0 Then
'teilen
End If
ist schneller als per Exception

Genau.

Sinn einer Exception ist, dass die Programmausführung abgebrochen wird, vorzugsweise im Designer.
Das gibt dir die Möglichkeit, sicher zu programmieren, nämlich den Fehler beheben (etwa Divisionen absichern gegen Teilung durch 0).

Inner IDE soll ein Prog abschmieren (100 mal ist nichtmal viel) - und jedesmal kannst du es verbessern.

Hingegen beim Kunden können 100 Abstürze schon logisch nicht vorkommen, weil nach dem dritten wirds vermutlich deinstalliert (Also der Arbeitsspeicher ist nicht das Problem, nichtmal bei C++ ).

Hey,

@jvbsl: Muss dir recht geben in dem Fall isses so:D wollte in dem Fall halt ne Exception provozieren

@ErfinderDEsRades: In der IDE ist es inordnung, da stört es ja niemanden, aber wenn es ausgeliefert wird sollte dass Programm niemals einfach so abstürzen klar ist hundertmal nicht viel und du hast auch in so fern recht dass der Ram normal kein Problem ist, weil wie du sagst nach drei abstüztzen normal das Programm eh fliegt.. Aber wenn du ein Speicherleck im Porgramm hast.. Ein großes Programm dass wärend dem Ablauf viel Anlegt, viel Speicher reserviert und normal(bsp. im Destructor) den Speicher wieder freigeben sollte:D (ist definitiv ne scheiß art das so zu machen soll es aber auch geben:P) dann ist er vllt. nicht mega voll aber es ist undefinierbarer Speicher reserviert.

Aber wir sollten dass Thema hier nicht weiter missbrauche wir können aber gerne über PN weiter reden wenn du willst:D

lg.

LucaWelker