"Lost Connection during Query" oder "wie kann ich dieses View erstellen"

[nahpets]

Bin mir nicht sicher, aber meine Vermutung ist, dass einfach die Menge der (eventuell sogar gleichzeitig) auf die Datenbank losgelassenen Abfragen, einfach die (Verbindungs-?)Kapazität zwischen Client und Datenbank übersteigt.

Schau bitte mal, ob es da technisch oder konfigurationsbedingt, irgendwelche Einschränkungen gibt.

Nehmen wir mal die Felgengröße als konkretes Problem:

Es können, für die vier Felgengrößen, zu beliebigen Zeiten, beliebig viele Änderungen eingepflegt werden.

Des weiteren gehen wir davon aus, dass Du Dich für die oben skizzierte "Feld"-Tabelle für die Felgengrößen entschieden hast.

Um diese Feldtabelle nun mit wenig Aufwand zu pflegen, könnte eventuell ein Datenbanktrigger für ein Insert in die Tabelle Reifenlager reichen.
Dieser Trigger wird immer dann von der Datenbank automatisch ausgeführt, wenn ein neuer Datensatz in die Tabelle Reifenlager eingefügt wird.
Innerhalb dieses Triggers müsste dann geprüft werden, ob es die Felgengrößen schon in der Feldtabelle gibt, wenn nicht, wird ein neuer Datensatz eingefügt.

Wenn aus dem Reifenlager ein Datensatz entfernt wird, so muss ein Trigger für das Ereignis Delete ausgeführt werden.
Dieser Trigger muss dann aus der Feldtabelle alle die Felgengrößen entfernen, die es nun in der Tabelle Reifenlager nicht mehr gibt.

Für Änderungen im Reifenlager muss es einen Trigger für das Ereignis Update geben. Hier ist dann zu prüfen, ob es alle Felgengrößen dieses Datensatzes schon in der Feldtabelle gibt, wenn nein, müssen sie hinzugefügt werden. Die Felgengrößen, die es nicht mehr gibt, müssen entfernt werden.

Ob das für die Datenbank dann weniger Arbeit ist und insgesamt schneller wird, als Deine bsher angedachte Lösung, vermag ich nicht zu sagen. Hier müsstest Du mal probieren, ob Du das mit My-SQL (da fehlt mir leider jegliche Erfahrung) realisieren kannst. Bei Oracle wüßte ich, wie ich vorgehen könnte, weiß aber nicht, ob und wie das auf andere Datenbanken übertragbar ist.

Zitat:

Gut, das könnte sein. Aber das Order by wird dann ja auch nicht mehr großartig Last verursachen, da ja schon alles 'sortiert' ist.

Naja, zumindest von Oracle kenne ich das so:

Zuerst wird das innere SQL ausgeführt, also die Unions un das Ergebnis wird sortiert. Es muss also temporär vorgehalten werden.

Anschließend wird das äußere SQL über die temporär vorgehaltenen Ergebnismenge ausgeführt und sortiert.

Ob und wieviel Last bei 'ner kleinen DAtenmenge dabei entsteht, mag ich nicht zu beurteilen.
Fakt ist, es ist überflüssig und sollte damit entfallen.
Auch viele, kleine, überflüssige, nur wenige resourcenverbrauchende, Abfragen erzeugen zusätzliche Laufzeit.
Und wenn mir ein System zu langsam ist, dann spare ich grundsätzlich alles ein, was Laufzeit kostet, auch wenn es (dem ersten Augenschein nach) nur auf die einzelne Abfrage sehr wenig ist.

Zitat:

Das wäre natürlich dann kein wirklicher Vorteil. Ist zwar schön, dass man sich dann etwas Schreibarbeit spart, aber wo ist der effektive Vorteil?

Naja, stell' Dir mal ein sehr komplexes System vor, in dem so ein Statement nicht mal eben in vier Zeilen "abzufackeln" ist, sondern eher mal ein paar hundert Zeilen lang wird.
Und nun wird dieses Statement nicht nur an einer Stelle benötigt, sondern an vielen, z. B. in einer Desktop-App, einem Webinterface, für den Reportgenerator ...

Nun muss man dieses Teil schon an drei Stellen pflegen. Mit 'ner View aber nur noch einmal.

Mal flappsig und überspitzt formuliert:
Alles was ich in Delphi mehr als einmal benötige wird zu 'ner Funktion oder Prozedure.

Jedes Select-Statement, das ich mehr als einmal benötige, wird zu 'ner View.

Ansonsten zur Fehlermeldung:

Schau bitte mal hier: https://www.benefind.de/web.php?q=%2...+mysql&org=307
Es scheint dort mehrere Lösungsansätze zu geben.

[p80286]

Eigentlich unglaublich, daß es diesen Fehler überhaupt gibt, aber sei's drum. Mit EarlyBirds Ansatz läzt sich der Fehler vermeiden (http://forums.mysql.com/read.php?61,...7705#msg-87705).
In einem View ist ein Sort meist überflüssig, da ein View oft nur Rohdaten für einen select zur Verfügung stellt. Der kann dann sortieren wie's gebraucht wird. Der Vorteil eines Views sind u.a. die entfallenden Prüfungen (Syntax). So ist ein select der Views nutzt im allgemeinen immer etwas schneller als ein größeres Select. So sollte es zumindest sein.
Und natürlich die Vorteile, die Stephan genannt hat, einmal testen, immer nutzen. Das als Schreibvereinfachung zu sehen ist schon stark untertrieben.

Gruß
K-H

[Captnemo]

Also, ich habe mir jetzt mal die Views erstellt. Ohne 'order by xxx' sind die Inhalte im MySQL dann unsortiert.

Aber das kann man erst mal vernachlässigen. Schlimmer ist, dass der Fehler "Lost connection during Query" damit trotzdem auftritt. Gefühlt nicht mehr so oft, aber er tritt auf.

Ich kannte das natürlich über eine Trigger lösen, der bei einem Insert oder Update eine Referenztabelle pflegt. Damit muss ich mich erst mal befassen.
Oder aber, ich mache ein einfaches Select auf meine 4 Felder, und lasse die im Thread zusammenführen und sortieren. Ist sicherlich nicht schneller.

Ein anderer Gedanke, der mir grade kam. Das das ein sehr altes Projekt ist, nutze ich dort immer noch die libmysql50.dll, könnte das evtl. das Problem auslösen.
Und was mir auch noch auffällt, dass scheinbar tritt der Fehler nur auf, wenn ich eine SQL-Abfrage in einem Thread laufen lasse. Was ich vorher in dem Projekt nie gemacht habe.
Das lässt mich annehmen, dass es evtl. nicht zwangsläufig am SQL-Server liegen muss.

[Medium]

Das kann dann ein Problem werden, wenn du z.B. im Thread Komponenten nutzt die du auf dein Formular gelegt hast. Ich hatte bei MySQL Zugriffen auch schon Probleme damit, weiss nur nicht mehr ob das bei Zeos oder UniDAC war. Ich erstelle seither immer alle Ressourcen dafür im Thread selbst, und habe keine Probleme mehr gehabt.
Wichtig dabei ist: Im Konstruktor des Threads erstellte Dinge sind nicht im Threadkontext!! Daher quasi so:

Delphi-Quellcode:

type
  TMyThread = class(TThread)
  private
    FServerName: String;
    FPort: Integer;
    FUsername: String;
    FPassword: String;
    FCatalog: String;
  protected
    procedure Execute; override;
  public
    constructor Create(aConnection: TZConnection (*zur einfachen Übernahme der Verbindungsinfos von einer Connection auf dem Formular*));
  end;

implementation

constructor TMyThread.Create(aConnection: TZConnection);
begin
  inherited Create(false);
  FServerName := aConnection.Servername;
  FPort := aConnection.Port;
  ...
end;

procedure TMyThread.Execute;
var
  connection: TZConnection;
  query: TZQuery;
begin
  connection := TZConnection.Create(nil);
  connection.ServerName := FServerName;
  ...
  query := TZQuery.Create(nil);
  query.Connection := connection;
  try
    repeat
      ...
    until Terminated;
  finally
    connection.Free;
    query.Free;
  end;
end;

Oder die Connection und Query als Feld des Threads, falls man mal ein paar mehr Thread-Methoden aufrufen will und diese nicht immer als Parameter mitgeben will.

[Captnemo]

Zitat von Medium:

Das kann dann ein Problem werden, wenn du z.B. im Thread Komponenten nutzt die du auf dein Formular gelegt hast. Ich hatte bei MySQL Zugriffen auch schon Probleme damit, weiss nur nicht mehr ob das bei Zeos oder UniDAC war. Ich erstelle seither immer alle Ressourcen dafür im Thread selbst, und habe keine Probleme mehr gehabt.

Tatsächlich scheint das das eigentliche Problem gewesen zu sein.
Ich habe jetzt auch mal die Connection direkt im Thread erstellt, und seither ist der Fehler auch nicht mehr aufgetreten.

Allerdings habe ich die Connection im Konstruktor erzeugt.

Zitat von Medium:

Wichtig dabei ist: Im Konstruktor des Threads erstellte Dinge sind nicht im Threadkontext!! Daher quasi so:

Das ist mir allerdings neu. Ich habe alles bisher immer im Konstruktor erzeugt und nie Probleme gehabt (Was ja nichts heißt). Kann man das irgendwo nachlesen?

[jobo]

Eine Anmerkung noch zum Union (keine Ahnung ob das hier oder im anderen Thread zur Sprache kam)
Ein Union (und natürlich erst Recht ein mehrfaches) baut implizit ein Group By bzw. Distinct in die Verarbeitung ein, um zu garantieren, dass es die redundanzfreie Vereinigungsmenge ist.
Auch wenn es nur 850 Sätze sind, kann das je nach Ausstattung und Abfragehäufigkeit unnötigen Streß (für den server) bedeuten.
Also
UNION ersetzen durch
UINION ALL

Das hängt ungeprüft und ungruppiert alles hintereinander. Macht auch und vor allem Sinn, wenn anhand des Datenmodells sicher gilt, dass eh keine Dubletten vorkommen können.

[Medium]

Zitat von Captnemo:

Das ist mir allerdings neu. Ich habe alles bisher immer im Konstruktor erzeugt und nie Probleme gehabt (Was ja nichts heißt). Kann man das irgendwo nachlesen?

Ja, in den VCL Quellen. Unter Windows wird ein Thread mit einem Aufruf von CreateThread() der WinAPI gestartet. Dies passiert im Konstruktor von TThread, und der Methodenzeiger, der dabei als Thread-Methode übergeben wird, ist eine Wrapper-Methode, die intern im Wesentlichen TThread.Execute aufruft. Der Konstruktor selbst ist dabei nicht Teil des Threads - der wird da ja erst erstellt. Sonst hätte man ja ein typisches Henne-Ei-Problem.

[Captnemo]

Danke für den Hinweis. Dann werde ich das noch mal ändern. Sicherheitshalber.