AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken [MySQL, UniDAC] Query vorzeitig abbrechen?
Thema durchsuchen
Ansicht
Themen-Optionen

[MySQL, UniDAC] Query vorzeitig abbrechen?

Ein Thema von Medium · begonnen am 28. Feb 2016 · letzter Beitrag vom 1. Mär 2016
Antwort Antwort
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#1

AW: [MySQL, UniDAC] Query vorzeitig abbrechen?

  Alt 28. Feb 2016, 23:12
Das du auf das Ende aller Threads warten musst, liegt natürlich auch daran, dass du einen Löck von deinem Chart-Objekt in jedem Thread verwendest.

Den "Throttle" würde ich auf jeden Fall auch verwenden, die Threads würde ich aber unabhängige Listen erstellen lassen und erst zum Abschluss diese Listen an das eigentliche Objekt zurückliefern.

Das sollte dein Problem im Prinzip lösen.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
zagota

Registriert seit: 3. Sep 2014
38 Beiträge
 
#2

AW: [MySQL, UniDAC] Query vorzeitig abbrechen?

  Alt 29. Feb 2016, 09:44
Bei den UniDAC-Komponenten gibt es die Möglichkeit FetchAll = False zu setzen.
Vielleicht hilft dir das weiter.

cu
  Mit Zitat antworten Zitat
Medium

Registriert seit: 23. Jan 2008
3.689 Beiträge
 
Delphi 2007 Enterprise
 
#3

AW: [MySQL, UniDAC] Query vorzeitig abbrechen?

  Alt 29. Feb 2016, 23:45
Das du auf das Ende aller Threads warten musst, liegt natürlich auch daran, dass du einen Löck von deinem Chart-Objekt in jedem Thread verwendest.
Der Lock betrifft nicht die ganze Abfrage, sondern nur diesen kleinen Block hier:
Delphi-Quellcode:
    FChart.FSeriesLock.Enter;
    try
      if Assigned(FChart.FSeries) then
        FreeAndNil(FChart.FSeries);
      FChart.FSeries := tmpSeries;
    finally
      FChart.FSeriesLock.Leave;
    end;
Es wird also im Thread erst eine temporäre Liste erstellt, die dann mit einer einfachen Referenzzuweisung an das Chart gegeben wird. (Und vorher die alte freigegeben natürlich.)
Theoretisch könnte ich das einfach laufen lassen und nachher nur per gesetztem Abort-Flag das Umhängen der Liste unterlassen bei abgebrochenen Threads. Ich hatte aber gehofft die gerade beim Scrollen mit der Maus dann schnell erzeugten 10-20 Queries die dann ja noch laufen der DB nicht zumuten zu müssen, die vor allem ja auch noch weiterhin sekündlich neue Daten die von einer Server-Applikation kommen wegschreiben muss. Fand's einfach unschön.
Die Verlangsamung kam dadurch, dass ich versucht habe den Thread aus dem Hauptthread heraus sauber inmitten einer SQL-Query abzubrechen - was scheinbar ein Ding der Unmöglichkeit ist.
Zitat:
Das sollte dein Problem im Prinzip lösen.
Im Prinzip tut es das auch, aber eben mit dem kleinen Nachteilchen, dass die DB unnötig weiterrödeln muss. Dank des "Throttles" dürfte das jetzt allerdings deutlich weniger und seltener sein, so dass ich mal probieren könnte auf KillThread() ganz zu verzichten!

@zagota: Wenn ich das richtig verstehe begrenzt das lediglich die Anzahl der Datensätze die übertragen werden. Die Query muss aber trotzdem vorher vollständig ausgeführt werden. Bei mir sind nicht große Datenmengen das Problem (maximal ~1000 Sätze pro Result, meistens eher um 500), sondern die Queries selbst.
Ich habe hier schon, für das was sie tut, wirklich gute Geschwindigkeiten. Dinge wie "Ermittle aus sekündlichen Messdaten den Durchschnitt, Minimum und Maximum für Zeitabschnitte von je X Sekunden und Y Minuten, gruppiert nach Zeitabschnitten, und das Summiert aus 3 (von ca. 500) Tabellen mit je knapp 8mio Datensätzen (bisher), im Zeitraum von 01.01.2016 bis 01.02.2016. In, je nach dem wie günstig man den Server gerade erwischt, 1-2 Sekunden, manchmal sogar drunter.) Gemessen an der Aufgabe ist das echt gut, aber zum immer vollständig neu Updaten beim herumscrollen und zoomen ist es zu langsam.
Die konkreten Zeitabschnitte ermittle ich aus der Breite des Charts, so dass niemals mehr als 1 Datensatz im Result pro Pixel Breite anfällt. Zu den sekündlichen Daten führe ich in den gleichen Tabellen auch die minütlichen und stündlichen bei jedem Update mit, die ich selektiere wenn 1px >= 1min bzw. Stunde ist. Bis auf die o.g. Kleinigkeit klappt das erfreulich gut. (Ja, die nötig werdende jährliche Festplattenarchivierung ist allen Beteiligten klar. Das ist i.O. (Das Datenbank-File hat jetzt schon, nach etwa 3,5 Monaten, ca. 150GB ))
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)

Geändert von Medium (29. Feb 2016 um 23:48 Uhr)
  Mit Zitat antworten Zitat
zagota

Registriert seit: 3. Sep 2014
38 Beiträge
 
#4

AW: [MySQL, UniDAC] Query vorzeitig abbrechen?

  Alt 1. Mär 2016, 06:39
@zagota: Wenn ich das richtig verstehe begrenzt das lediglich die Anzahl der Datensätze die übertragen werden. Die Query muss aber trotzdem vorher vollständig ausgeführt werden. Bei mir sind nicht große Datenmengen das Problem (maximal ~1000 Sätze pro Result, meistens eher um 500), sondern die Queries selbst.
Habe ich nicht versucht, bei einer Sortierung wird die Query sicherlich vollständig ausgeführt.
cu

Geändert von zagota ( 1. Mär 2016 um 07:12 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:34 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz