MySQL-Datenbank -> DataSet

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von tragl.

    MySQL-Datenbank -> DataSet

    Hallo zusammen.

    Ich arbeite in meinem Programm mit typDataSet und angeschlossener MySQL-Datenbank.
    Aktuell muss ich an einer großen Tabelle etwas ändern und da ist mir aufgefallen, dass es verdammt lange dauert bis das Laden der
    Daten aus der Datenbank abgeschlossen ist.

    Für die Aktion, Command und Anzahl Ergebnisse hab ich ne Debug-Ausgabe, die sieht wie folgt aus:

    Quellcode

    1. 3 Fill
    2. SELECT `DataLog`.* FROM `DataLog`
    3. 133008 Results


    Die erscheint ziemlich direkt nach dem Start des Ladevorgangs (ein paar Millisekunden), jetzt wundert mich aber, warum das so lange dauert bis der Vorgang abgeschlossen ist.
    Das Laden dauert 2-3 Minuten, der Prozessspeicher erhöht sich jedoch nicht, die CPU-Auslastung auch nicht. Wisst ihr, was da im Hintergrund passiert? Muss das im DataSet noch zugeordnet werden?

    Mich wundert's nur, denn in der MySQL-Workbench hab ich in ein paar Millisekunden meine Einträge...


    das sollte in meinem Programm eigentlich ja auch nicht länger dauern...
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Wenn das tDS noch über BindingSource an ein DGV gekoppelt ist, dann wär es kein Wunder. Setz die GUI-Kopplung aus, um zu sehen, ob es dann schneller geht. Mehr als 5 Sekunden sind m.E. hochverdächtig.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @VaporiZed:

    Naja, im o.g Fall hab ich eine Sub direkt nach dem Start ausgeführt. Es ist nur die frmMain mit ein paar DGV zu sehen - keines der DGV hat was mit der
    Tabelle zu tun. Es sind aber andere Bindingsources des tDS an die DGV's gebunden.

    Muss dann "alles" entkoppelt und danach wieder gebunden werden? Wie stell ich sowas an?
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Es gibt mehrere, unterschiedlich effektive Wege:
    • der einfachste, wenn auch nicht effizienteste Weg: Programmbackup machen, DGVs löschen, testen.
    • DeinDGV.SuspendLayout und DeinDGV.ResumeLayout
    • DeineBS.SuspendBinding und DeineBS.ResumeBinding

    • VB.NET-Quellcode

      1. Dim DataSource = DeinDGV.DataSource
      2. DeinDGV.DataSource = Nothing
      3. 'hier Daten laden
      4. DeinDGV.DataSource = DataSource
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @VaporiZed

    @ErfinderDesRades: Ich hol dich mal mit dazu, da die Persistance ja von dir stammt, evtl. hast du eine Idee dazu.

    Ich hab mal ein kleines Testprojekt angehangen.
    Man kann Daten erzeugen, löschen, anschauen - über den Tree oder öffnen von "Tabelle anzeigen".
    Für die Testdaten werden Einträge erzeugt und auch gelöscht (Anzahl kann man in logic.vb einstellen).
    Gestoppt wird jeweils die Zeit nach der reinen "Erstellung" bzw. "Löschung" und direkt danach nochmal für das Speichern.

    Für das reine Erstellen und Löschen geht das super schnell - die Übertragung zur Datenbank (beim Speichern) sorgt für die enorme Verzögerung.
    Dabei macht es keinen Unterschied, ob die DataSource des DGV da ist oder nicht. (Zumindest würde ich behaupten, dass das Messtoleranz ist).

    Umschalten zwischen Datenbank und XMl geht in der frmMain Zeile 6: App.PersistancemodeXml =
    True=XML
    False=Datenbank


    Beispiel mit Datenbank:

    Aktion mit 2.000 Test-Daten
    		Erzeugen (Sekunden)
    		inkl. Speichern (Sekunden)
    Aufruf Tree Test-Daten erzeugen
    		0,0031177
    		5,1033144
    Aufruf Tree Test-Daten löschen
    		0,0047921
    		5,2246692
    Aufruf Tree Tabelle anzeigen


    -> Klick Daten erzeugen (DataSource des DGV wird deaktiviert)
    		0,0025466
    		5,0297023
    -> Klick Daten löschne
    (DataSource des DGV wird deaktiviert)

    		0,0032997
    		5,0323341

    Beispiel mit XML-Datei:

    Aktion mit 2.000 Test-Daten
    		Erzeugen (Sekunden)
    		inkl. Speichern (Sekunden)
    Aufruf Tree Test-Daten erzeugen
    		0,002639
    		0,0070603
    Aufruf Tree Test-Daten löschen
    		0,0024688
    		0,0034408
    Aufruf Tree Tabelle anzeigen


    -> Klick Daten erzeugen (DataSource des DGV wird deaktiviert)
    		0,0025862
    		0,0053091
    -> Klick Daten löschne
    (DataSource des DGV wird deaktiviert)
    		0,0032912
    		030042436

    PS: Ja, wir reden hier von 2.000 Datensätzen, die 5 Sekunden kann man natürlich warten. Ich hantiere aber teilweise mit wesentlich mehr (10.000+) und da sind 30 Sekunden+ schon nervig ;)
    Würde mich freuen, wenn wir das gelöst bekommen, denn die Abfragen in der Datenbank selbst gehen ja auch innerhalb weniger Sekunden oder sogar Millisekunden.
    Dateien
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

    Nachdem ich es endlich alles korrekt verlinkte hatte, kam ich zumindest zum Punkt, dass folgende Methode der Flaschenhals ist - bei mir noch mehr als bei Dir. Es dauert mit dem DB-Speichern 25 Sekunden ;(

    VB.NET-Quellcode

    1. Public Function Update(rows As DataRow()) As Integer
    2. Return Adapter.Update(rows)
    3. End Function

    Bei dem Thema bin ich aber raus. tDS-DB-Anbindung ist nicht mein Ding. Außerdem ist das eine EdR-Bibliothek. Da halt ich mich raus.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    VaporiZed schrieb:

    alles korrekt verlinkte hatte

    Was meinst du mit verlinken? Ich hatte extra alles "schmal" gehalten, hatte sogar mein eigenes Helfer-Projekt rausgeschmissen, damit keine unzähligen NuGets geladen werden müssen.

    Die Function sieht für mich allerdings korrekt aus. Der DataAdapter sorgt für das Update der Rows in der Datenbank - ich denk mal, das wäre auch bei einem "normalen" DataAdapter
    so
    "Na, wie ist das Wetter bei dir?"
    "Caps Lock."
    "Hä?"
    "Shift ohne Ende!" :thumbsup:

Facebook
Telefonspende