Query springt nicht zum ersten Datensatz

[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 von jobo:

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?

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

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

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

[wjjw]

Zitat von 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;

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 von wjjw:

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.

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