Query springt nicht zum ersten Datensatz

[Ykcim]

Hallo Zusammen,

ich habe ein für mich nicht erklärbares Problem mit einer UniQuery von UniDac.

Ich habe alle Einstellungen meiner Software in einer Tabelle gespeichert, mit den Spalten:
ID: für den Schlüssel
einstellung: um was für eine Einstellung handelt es sich - danach wird auch gesucht
wert: das ist der eigentliche Wert der Einstellung
kommentar: hier wird die Einstellung die Zusammensetzung der Werte erklärt.

Dann habe ich eine Function geschrieben, um die Einstellung schnell abholen zu können, ohne ständig auf die DB zugreifen zu müssen. Das heißt ich halte die Daten in der Query und hole sie bei Bedarf mit der Function Find_Property(einstellung, spalte: string):string raus. Spalte gibt an, aus welcher Spalte der Einstellungswert zu holen ist. Ich habe auch eine Variante, wo eine Einstellung mehrere werte haben kann...

Delphi-Quellcode:

function TMySQLDB.Find_Property(Einstellung, Spalte: string): string;
var   I: integer;
begin
   Result:='';
   FQuery_Einstellungen.First;   //das scheint wirkungslos zu sein
   if FQuery_Einstellungen.Bof then begin   //zum Testen eingebaut
      while (not FQuery_Einstellungen.Eof) and (FQuery_Einstellungen.FieldByName('Einstellung').AsString<>Einstellung) do begin
         FQuery_Einstellungen.Next;
      end;
      if FQuery_Einstellungen.FieldByName('Einstellung').AsString=Einstellung then begin
         Result:=FQuery_Einstellungen.FieldByName(Spalte).AsString;
      end;
   end;
end;

Eigentlich läuft die Funktion gut, aber auf einmal springt sie nicht mehr zum ersten Datensatz, sondern bleibt auf dem letzten stehen.
Die Query hat 53 Datensätze, was ich geprüft habe.

Hat jemand eine Idee?

Vielen Dank
Patrick

[haentschman]

Moin...8-)

Delphi-Quellcode:

while (not FQuery_Einstellungen.Eof) and (FQuery_Einstellungen.FieldByName('Einstellung').AsString<>Einstellung) do begin 
// <>  heißt, wenn die Einstellung nicht gefunden wird, gehe zum nächsten Datensatz...es fehlt die Abbruch Bedingung. :-) 
  FQuery_Einstellungen.Next; // das hast du auch programmiert :-)
end; // Am Ende steht der Datensatz auf dem Letzten

Ich könnte dir das umschreiben...aber du sollst es allein finden. :thumb:

[Jumpy]

Ich kenne Unidac nicht, aber gibt es da kein Locate o.ä.?

[hoika]

Hallo,

Zitat:

sondern bleibt auf dem letzten stehen

Hast Du mal die Schleife durchdebuggt?

Gibt es bei der Query ein Property UniDirectional?
Wenn ja, setze das mal auf False.
(Müßte es geben: https://forums.devart.com/viewtopic.php?t=17738)

Zitat:

Das heißt ich halte die Daten in der Query

Das könntest Du ach mit einem TClientDataSet hinbekommen.

[Ykcim]

Die Bedingungin der while-Schleife soll eigentlich heißen:
Solange Du nicht am Ende angekommen bist (eof) und Du die Einstellung nicht gefunden hast, dann Query.Next. Damit wird der nächste Datensatz angesprochen.

Aber die Query bleibt auf dem letzten Datensatz stehen...

[jobo]

Wie kommst Du darauf, das First sei wirkungslos?
Wenn man nur Next macht und am Ende angekommen ist, gibt es die Einstellung, die Du suchst halt nicht.

[haentschman]

Zitat:

dann Query.Next. Damit wird der nächste Datensatz angesprochen.

...und was passiert mit NEXT? Der Datensatzzeiger wird verschoben...und wo sitzt der Datensatzzeiger nach der Schleife? :zwinker:

Zitat:

Das könntest Du ach mit einem TClientDataSet hinbekommen

Zitat:

Ich kenne Unidac nicht, aber gibt es da kein Locate o.ä.?

...das hilft aber nicht bei offensichtlichen Logikfehlern. :?

[Ykcim]

Zitat:

Hast Du mal die Schleife durchdebuggt?

Ja, habe ich versucht. Aber da die Query auf dem letzten Datensatz steht, springt er sofort aus der Schleife heraus...

Zitat:

Gibt es bei der Query ein Property UniDirectional?
Wenn ja, setze das mal auf False.

Ja, gibt es, hatte aber leider keinen Effekt...

Zitat:

...und was passiert mit NEXT? Der Datensatzzeiger wird verschoben...und wo sitzt der Datensatzzeiger nach der Schleife?

Der Datenzeiger steht auf dem letzten Datensatz.

Deshalb wollte ich

Delphi-Quellcode:

FQuery_Einstellungen.First

nutzen, um zum ersten zu springen und dann die Schleife laufen zu lassen. Aber das bleibt ohne Effekt. Bei debuggen kann ich sehen, dass der Wert des letzten Datensatzes ausgegeben wird....

[Lemmy]

keine Lösung, dafür Fragen...

wie sieht der Wert von FQuery_Einstellungen.FieldByName('Einstellung').As String vor und nach FQuery_Einstellungen.First; aus? das schon geprüft? Oder wie stellst Du fest, dass First keine Wirkung hat?

Wie ist der Wert von FQuery.SQL.Text beim Eintritt in die Methode?

[jobo]

Und wenn schon dynamisch per Query, warum machst du nicht gleich eine Query, die genau den gesuchten Wert holt, statt dieses "Gehampel" (zum Glück jetzt nur max. 53 Mal nachschauen und weiterschalten). Wenn es tausende Einstellungen wären, würde man wahrscheinlich gar nicht ert auf die Idee kommen, jeden lokal abzurufen und nachzuschauen, ob es die Einstellung ist, die man eigentlich braucht.

Query.sql.add('where <spalte> = :Einstellung')
Ergebnis: Leere Menge = Einstellung gibt's nicht in <spalte> bzw. Tippfehler im Parameter
Ergebnis: Ein Datensatz = Treffer
Ergebnis: Mehr = nicht eindeutig... > Fehler im Datenmodell

[Lemmy]

Zitat:

Zitat von jobo (Beitrag 1426703)

Und wenn schon dynamisch per Query, warum machst du nicht gleich eine Query, die genau den gesuchten Wert holt, statt dieses "Gehampel" (

warum einfach, wenn es auch kompliziert geht? ;-)

[haentschman]

Zitat:

keine Lösung, dafür Fragen..

Ich kürze das mal ab...

Delphi-Quellcode:

function TMySQLDB.Find_Property(Einstellung, Spalte: string): string;
var I: integer;
begin
   Result := '';
   FQuery_Einstellungen.First; 
   while not FQuery_Einstellungen.Eof do
   begin
      if FQuery_Einstellungen.FieldByName('Einstellung').AsString = Einstellung then 
      begin
        Result := FQuery_Einstellungen.FieldByName(Spalte).AsString;
        Break;
      end;
     FQuery_Einstellungen.Next;
   end;
end;

[Jumpy]

Zitat:

Zitat von haentschman (Beitrag 1426699)

Zitat:

Ich kenne Unidac nicht, aber gibt es da kein Locate o.ä.?

...das hilft aber nicht bei offensichtlichen Logikfehlern. :?

Das stimmt schon, aber dann wäre das ganze Schleifen-Geraffel nicht nötig und dann wäre auch der Fehler weg.
Wenn man es aber schon mit Schleife macht, wäre es vllt. sinngemäß so einfacher:

Delphi-Quellcode:

Result:='Default oder Dummy oder nix';
Query.First
while not Query.EOF do
  begin
  if Query.FieldByName('Eingabe').AsString='Eingabe' then
    begin
    Result:=Query.FieldByName('Angabe').AsString;
    break;
    end;
  Query.Next
  end;

Nützt aber natürlich nix, wenn Query.First wirklich nicht funzt wegen unidirectionalem Cursor o.ä.

Evtl. kann man die Query nur lokal in der Funktion benutzen und jedes mal neu aufmachen, dann steht sie autom. immer auf dem ersten Datensatz.

[Ykcim]

Zitat:

wie sieht der Wert von FQuery_Einstellungen.FieldByName('Einstellung').As String vor und nach FQuery_Einstellungen.First; aus? das schon geprüft? Oder wie stellst Du fest, dass First keine Wirkung hat?

Es bleibt der Wert vom letzten Datensatz. Query.First hat keine Auswirkung...

Zitat:

Wie ist der Wert von FQuery.SQL.Text beim Eintritt in die Methode?

Delphi-Quellcode:

'select * from einstellungen'

Zitat:

Und wenn schon dynamisch per Query, warum machst du nicht gleich eine Query, die genau den gesuchten Wert holt, statt dieses "Gehampel" (zum Glück jetzt nur max. 53 Mal nachschauen und weiterschalten). Wenn es tausende Einstellungen wären, würde man wahrscheinlich gar nicht ert auf die Idee kommen, jeden lokal abzurufen und nachzuschauen, ob es die Einstellung ist, die man eigentlich braucht.

Query.sql.add("where <spalte> = :Einstellung")
Ergebnis: Leere Menge = Einstellung gibt's nicht in <spalte> bzw. Tippfehler im Parameter
Ergebnis: Ein Datensatz = Treffer
Ergebnis: Mehr = nicht eindeutig... > Fehler im Datenmodell

Ich wollte nach Möglichkeit nicht ständig eine Abfrage auf der Datenbank machen...

Ich weiß nicht warum Query.First keinen Effekt hat. Bislang hatte ich die Wert in ein Array geladen, da funktionierte es natürlich. Aber das musste ich aus einem anderen Grund ändern.

So scheint es aber auch zu funktionieren... Ich nach dem Hinweis mit Locate, loacate den Datensatz mit der procedure Query.locate und nehme dann den Wert aus der Spalte 'Spalte'... Anders herum gedacht, sieht aber ganz gut aus und ist sogar einfacher...

Delphi-Quellcode:

function TMySQLDB.Find_Property(Einstellung, Spalte: string): string;
begin
   Result:='';
   FQuery_Einstellungen.Locate('einstellung',einstellung,[]);
   if FQuery_Einstellungen.FieldByName('Einstellung').AsString=Einstellung then begin
      Result:=FQuery_Einstellungen.FieldByName(Spalte).AsString;
   end;
end;

Vielen Dank
Patrick

[haentschman]

Zitat:

Ich weiß nicht warum Query.First keinen Effekt hat

...weil du die Posts nicht gelesen hast. :roll:

PS: [meine Meinung]Von Locate rate ich ab. Funktioniert mal, mal nicht.[/meine Meinung]

[Ykcim]

Zitat:

...weil du die Posts nicht gelesen hast.

Sorry, den hatte ich tatsächlich übersehen! Damit klappt es...

Vielen Dank
Patrick

[Jumpy]

Locate sollte eigentlich auch true zurückgeben, wenn der Datensatz gefunden wurde, so dass man auch schreiben kann:

if Query.Locate() then
Result:=Query.FieldByName()


@haentschman: Kannst du das mit dem Locate-Problemen konkretisieren? Sind das bestimmte Szenarien, wo das nicht geht? Benutze das recht oft (mit TADOQuery allerdings) und hatte noch keine Probleme.

[haentschman]

@Jumpy:
Mein Problem: https://www.delphipraxis.net/199191-...ter-mssql.html
Probleme anderer: https://www.google.de/search?source=...19.4Maj-avE8Wc

[hoika]

Hallo,

Zitat:

warum machst du nicht gleich eine Query

Steht doch ganz oben.
Die Query wird als Datenspeicher benutzt und muss nur einmal ausgeführt werden.

[p80286]

Das halte ich für Sparen am falschen Ende. Meiner Meinung nach sollte der Ablauf ungefähr so sein:

Code:

Hole Parameter1
Hole Parameter2
...
Hole ParameterN

Was der TE tut ist

Code:

Hole alle vorhandenen Parameter
Hole aus der Ergebnismenge Parameter1
Hole aus der Ergebnismenge Parameter2
...
Hole aus der Ergebnismenge ParameterN

Der vom TE gewählte Weg ist erst bei einer großen Menge Parametern und/oder einer extrem langsamen DB - Anbindung effizenter.
Vor allem der Umgang mit fehlenden Werten ist im zweiten Fall aufwendiger, da es mindestens zwei Orte (DB und Ergebnismenge) gibt an denen geprüft werden muß ob die gewünschten Werte vorhanden sind.
Und das gerne genommene

SQL-Code:

Select * from...

kann im ungünstigen Falle so viel überflüssige Daten liefern, daß ein möglicher Performancevorteil aufgezehrt wird.

Gruß
K-H

[wjjw]

Zitat:

Zitat von Jumpy (Beitrag 1426711)

Locate sollte eigentlich auch true zurückgeben, wenn der Datensatz gefunden wurde, so dass man auch schreiben kann:

if Query.Locate() then
Result:=Query.FieldByName;

Ich muss da Jumpy zustimmem. Locate funktioniert ohne Probleme, wenn man die Query richtig konfiguriert (alle Daten liest). Verwende auch UniDAC mit diversen Datenbanken ohne Probleme.

Jedoch wenn es sich um ca. 50 Einstellungen handelt würde ich jedoch auch keine Query immer beschäftigen.
Besser ich lese die Daten aus der DB und schreibe sie in eine Struktur.
if Einstellung.Farbe=rot then ...
Auch besser lesbar und schneller.

[jobo]

Zitat:

Zitat von wjjw (Beitrag 1426729)

Jedoch wenn es sich um ca. 50 Einstellungen handelt würde ich jedoch auch keine Query immer beschäftigen.
Besser ich lese die Daten aus der DB und schreibe sie in eine Struktur.
if Einstellung.Farbe=rot then ...
Auch besser lesbar und schneller.

Das würde ich auch so sehen. Eine ähnliche Lösung gab es ja offenbar zuvor. In dem Zusammenhang fänd ich noch spannend, warum überhaupt von Array auf Query umgestellt wurde.

[rokli]

Zitat:

Zitat von p80286 (Beitrag 1426726)

Das halte ich für Sparen am falschen Ende. Meiner Meinung nach sollte der Ablauf ungefähr so sein:
[CODE]
Der vom TE gewählte Weg ist erst bei einer großen Menge Parametern und/oder einer extrem langsamen DB - Anbindung effizenter.
Vor allem der Umgang mit fehlenden Werten ist im zweiten Fall aufwendiger, da es mindestens zwei Orte (DB und Ergebnismenge) gibt an denen geprüft werden muß ob die gewünschten Werte vorhanden sind.
Und das gerne genommene

SQL-Code:

Select * from...

kann im ungünstigen Falle so viel überflüssige Daten liefern, daß ein möglicher Performancevorteil aufgezehrt wird.

Gruß
K-H

Mit dem Sparen am falschen Ende hast Du ja soooo recht! Was ist denn wenn der Inhalt der DB von einer anderen Person/Software geändert wird? Diese Änderung würde von der laufenden Anwendung niemals bemerkt, es sei denn, der User startet sein Programm zwischendurch (aber in welchem Intervall) immer wieder neu.

Das mit dem SELECT * FROM ... stimmt natürlich, ist aber die Entscheidung des Programmierers, ob er es langsam oder schnell gestaltet.

[Ykcim]

Zitat:

In dem Zusammenhang fänd ich noch spannend, warum überhaupt von Array auf Query umgestellt wurde.

Ich habe eine Klasse in einer eigenen Unit definiert, in der ich alle Query's ausführe. Diese Klasse ist in den Units, wo sie gebraucht wird verfügbar und damit dann auch die Daten. Diese Klasse hatte ich bis jetzt noch nicht. Zwar hätte ich das Array dort auch definieren können. Aber so fand ich es charmanter... Geschmackssache...