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

[Captnemo]

Zitat von nahpets:

Nur erstmal so ein paar hingeworfenen "Gedankensplitter"

Selects, die per Union zusammengefügt werden, werden zur Dublettenbeseitigung von der Datenbank sortiert. Das Order by kann daher eigentlich entfallen, es wäre zumindest schon mal eine "Optimierungsmöglichkeit".

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.

Zitat von nahpets:

Wie oft werden die Felgengrößen verändert, ergänzt ...?


Eher sporadisch?

Das ist je nach Jahreszeit unterschiedlich.

Zitat von nahpets:

Dann erstelle Dir eine Tabelle in der Form:

Code:

create tbl_Felgengroessen as
    select s_vl_felgengroesse as Feld from Reifenlager t1 union
      select s_vr_felgengroesse as Feld from Reifenlager t1 union
      select s_hr_felgengroesse as Feld from Reifenlager t1 union
      select s_hl_felgengroesse as Feld from Reifenlager t1) t21

(Eventuell ist bei Deiner Datenbank die Syntax etwas anders, bitte ausprobieren)

Die Tabelle bindest Du dann überall dort ein, wo Du bisher Deine Union-Abfrage nutzt. Das dürfte den Aufwand, den die Datenbank betreiben muss, etwas reduzieren.

Das könnte ich natürlich auch machen. Aber diese Tabelle müsste ja auch immer wieder auf den aktuellen Stand gebracht werden. Das wollte ich ja im Grunde mit der View erreichen.

Zitat von nahpets:

Du musst halt sicherstellen, dass diese Tabelle immer dann neu erstellt wird, wenn es bei den Felgengrößen eine Änderung gab.

Ob zur Laufzeit nun Dein Select ausgeführt wird oder die (momentan) nicht erstellbare View, dürfte egal sein. Bei einer Abfrage auf die View muss die Datenbank ja das dahinterliegende Select ausführen.

Das ist vielleicht mein Denkfehler. Ich habe Views noch nie genutzt. Ich hatte gedacht das ein View vom SQL-Server immer dann aktualisiert wird, wenn sich an den Referenztabellen Daten verändern. Quasi auf Verdacht, so dass die Daten im View bei Bedarf bereit fix und fertig zur Verfügung stehen, und nicht erst erzeugt werden müssen, wenn die Abfrage kommt.

Zitat von nahpets:

Eventuell lässt sich die View so erstellen:

Code:

create view v_Reifengroessen as
select s_vl_felgengroesse as Feld from Reifenlager 
union
select s_vr_felgengroesse as Feld from Reifenlager 
union
select s_hr_felgengroesse as Feld from Reifenlager 
union
select s_hl_felgengroesse as Feld from Reifenlager

Spitz formuliert ist die View ja nur eine "Schreibvereinfachung" für ein mehr oder weniger komplexes SQL-Statement.

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?

Zitat von nahpets:

Die Idee von EarlyBird mit zwei View ist ganz nett, aber ein

Code:

Select Feld from test1 order by feld

unterscheiden sich wohl weder im Aufwand noch im Ergebnis von

Code:

Select Feld from test2 order by feld

Oder: Die zweite View ist meiner Meinung nach entbehrlich.

Das werde ich mal ausprobieren.

Zitat von nahpets:

Auch wenn die Datenmenge von 850 Sätzen jetzt nicht wirklich nach sehr viel aussieht, so dürfte die Häufigkeit der Abfragen die Datenbank doch schon etwas ans Schwitzen bringen.

Deswegen bekomme ich wahrscheinlich auch das "Lost Connection during Query". Obwohl die Abfrage trotzdem gefühlt nur 1 oder 2 Sekunden dauert. Es wundert mich doch schon.

Zitat von nahpets:

In welcher Form benötigst Du die Ergebnisse dieser Abfragen im Programm?

Als Nachschlagtabellen, Inhalte von Listboxen ...?

Eventuell reicht es ja aus, wenn Du die Abfragen nur beim Programmstart lädst und dann innerhalb des Programmes in Listen bereithälst.

Genau. Ich brauch sie für eine Combobox, für die Auswahl durch den User.
Ich könnte sie natürlich bei Programmstart laden. Da die Anwendung aber den ganzen Tag am Stück läuft, würden sich die Einträge nicht mehr aktualisieren. Und bei 10 Benutzern, würde das gerade in den Jahreszeiten wo sich genau diese Daten stark verändern dazu führen, dass der eigentliche Nutzen nicht mehr so unbedingt gegeben ist. Wenn ein neues Element hinzugekommen ist, soll diese am gleichen aber auch an anderen Arbeitsplätzen gleich zur Verfügung stehen. Schon allein um unterschiedliche Schreibweisen möglichst zu vermeiden.

Außerdem ändert das ja nichts an dem Problem. Dann würde im schlimmsten Fall die Fehlermeldung gleich zu Beginn kommen.
Und gerade weil diese Abfrage ja ein wenig länger braucht, als ein einfaches Select habe ich das in ein Thread gepackt.
Wenn im dem nur eine diese Abfragen laufen würde, wäre es vielleicht auch noch kein Problem, aber ich muss das für 10 verschiedenen Felder machen. Und zwischen den Abfragen innerhalb des Thread noch Sleeps einzufügen würde dessen Laufzeit auch wieder unnötig verlängern.

Wenn alle Stricke reißen, dann müsste ich halt die per union verknüpften Abfragen im Thread einzeln machen und dort zusammensetzen.

Mich wundert aber trotzdem, dass der Fehler "Lost Connection during Query" auftritt. Er kommt definitiv nur wenn ich die Query mit Union ausführen lasse. Lasse ich die Weg, habe ich kein Problem mehr. Nach allem was ich gelesen habe, kommt diese Fehlermeldung aber nicht vom Zeos selbst, sondern von der libmySQL50.dll und wird von Zeos nur weitergereicht. Von daher kann ich daran programmmäßig auch nicht wirklich viel ändern. Ein Timeout einstellen kann ich meines Wissens nicht. Außer vielleicht in der my.cnf.

[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.

[Medium]

Zitat von Captnemo:

Das ist vielleicht mein Denkfehler. Ich habe Views noch nie genutzt. Ich hatte gedacht das ein View vom SQL-Server immer dann aktualisiert wird, wenn sich an den Referenztabellen Daten verändern. Quasi auf Verdacht, so dass die Daten im View bei Bedarf bereit fix und fertig zur Verfügung stehen, und nicht erst erzeugt werden müssen, wenn die Abfrage kommt.

Das trägt jetzt evtl. nicht wirklich zur Problemlösung bei, aber zur Natur von Views: Ein View ist vom Konzept her datenlos, und eigentlich, naiv gesehen, nicht viel mehr als ein Select, dass die eigentlich dahinter liegende normalisierte Tabellenstruktur zur einfacheren Benutzung in ein semantisch sinnvolle Ansicht überführt. Es ist fast wie ein prepared Statement - und da ist mein Latein dann auch am Ende - ich weiss nicht genau was, ausser der Persistenz über eine Session hinaus, ein View anders macht als ein prepared Statement. Aber zumindest hält ein View keine eigene Tabelle, die irgendwie aktualisiert werden müsste. Die Selects werden immer live ausgeführt. (Oder halt aus dem Cache, wie jedes andere Select auch.)

[hoika]

Hallo,
es gibt Views, die tatsächlich Daten enthalten (materialized views),
siehe hier https://docs.oracle.com/cd/B10501_01...7/repmview.htm

dass ist hier aber nicht verwendbar (wegen Oracle, und Nutzung für Replikation).

Ein anderer Nutzungsaspekt bei Views ist die Rechteverwaltung.
Ich kann einem Nutzer das (Select-)Recht zur Ausführung eines Views geben,
ihm aber aber sämtliche Rechte der zugrundliegenden Tabellen wegnehmen.


Heiko