[FMX] FDQuery.FieldByName leifert falschen String

[Hobbycoder]

Hi,

ich habe unter FMX ein Query welches eine Tabelle einer SQLite-DB abfragt. Es existiert lediglich eine Zeile in der DB.
Laut DB-Viewer befindet sich im Feld "username" ein String. (Siehe Bild DBViewer.png im Anhang)

In der Routine liefert mir FieldByName('username').AsString aber immer '0' zurück, und ich kann's mir nicht erklären. Mir ist auch nicht klar, wo er sich die '0' herholt. Wenn er irgendwas nicht lesen oder finden kann, dann sollte nur ein Leerstring kommen.

ich habe das Feld "username" schon mal umbenannt in "loginname" (vielleicht Schlüsselwort der DB), aber das änderte nichts.
Eigentlich sollte das Verhalten gar nicht möglich sein. Es tritt keine Exception auf.

Hier mal die Routine:

Delphi-Quellcode:

function TfrmTPMain.GetUsernameFromDB: string;
var
  q: TFDQuery;
begin
  Result:='';
  q:=TFDQuery.Create(nil);
  try
    q.Connection:=TPDatenmodul.conLocalsqlConnection;
    q.SQL.Text:='select * from global';
    q.Active:=True;
    if q.RecordCount>0 then
    begin
      q.First;
      Result:=q.FieldByName('loginname').AsString;
    end;
    q.Active:=False;
  finally
    q.Free;
  end;
end;

Im Anhang habe ich noch mal Screenshots vom Debug-Screen und der DB. Da kann man deutlich sehen, was q.FieldByName('loginname').AsString zurückliefert und was in der DB steht.

Wie gesagt, ich kann's mir nicht erklären.

[p80286]

Versuch es mal mit

Delphi-Quellcode:

q.OPEN;

Gruß
K-H

[mkinzler]

Ersetzte mal

Delphi-Quellcode:

q.Active := True;

durch

Delphi-Quellcode:

q.Open;

und

Delphi-Quellcode:

q.Active:=False;

durch

Delphi-Quellcode:

q.Close;

Heisst das Feld nun username oder loginname?

[Hobbycoder]

Und schon Problem selber gelöst (leider erst nachdem ich den Thread abgeschickt hatte).

Falls jemand mal änliches Verhalten hat hier die Ursache.

Mit ausreicht Kenntnisse über SQLite hätte ich es vielleicht wissen können, aber man kann tatsächlich einen Feldtyp von Text in Real ändern (in diesem Fall ist das versehendlich passiert), und alle Textwerte belieben in der Tabellenspalte vollständig erhalten. Und leider ist mein DB-Viewer so, dass er prompt den Textinhalt anzeigt.
FireDAC aber aufgrund des Fehdtypes konsequent 0 zurückliefert.

Wie gesagt, auf Grund der Tatsache, dass hinter SQLite keine DB-Server steckt, hätte ich auch eher drauf kommen können.

[Hobbycoder]

Zitat:

Zitat von mkinzler (Beitrag 1447877)

Ersetzte mal

Delphi-Quellcode:

q.Active := True;

durch

Delphi-Quellcode:

q.Open;

und

Delphi-Quellcode:

q.Active:=False;

durch

Delphi-Quellcode:

q.Close;

Macht das einen Unterschied Open vs Actice:=True bzw. Close vs Active:=False?
Habe bisher immer Active:= verwendet.

Zitat:

Zitat von mkinzler (Beitrag 1447877)

Heisst das Feld nun username oder loginname?

Jetzt loginname, weil ich es zum Testen verändert hatte. Screenshot war davor, Code im Thread aber danach. Daher der Unterschied

[mkinzler]

DataSet.Active dient eigentlich nur zur Anzeige des Status.

[TigerLilly]

"Eigentlich?"

Active ist eine beschreibbare Property, die intern auf Open/Close routet. Es ist doch wohl egal, ob man eine Query mit Open oder Active öffnet.

[p80286]

Naja so ganz das gleiche ist das wohl nicht:

Zitat:

Call Open to set the Active property for the dataset to true. When Active is true, data can be populated with data. It can read data from a database or other source (such as a provider). Depending on the CanModify property, active datasets can post changes.

Setting Active to true:

Triggers the BeforeOpen event handler if one is defined for the dataset.

Sets the dataset state to dsBrowse.

Establishes a way to fetch data (typically by opening a cursor).

Triggers the After Open event handler if one is defined for the dataset.

If an error occurs during the dataset open, dataset state is set to dsInactive, and any cursor is closed.

Ich pers. würde Anmerkungen von Markus immmer sehr ernst nehmen. Aber das ist meine ganz pers. Ansicht.

Gruß
K-H

[TigerLilly]

1) http://docwiki.embarcadero.com/RADSt...osing_Datasets

2)

Delphi-Quellcode:

procedure TDataSet.Open;
begin
  Active := True;
end;

Übersehe ich etwas?

[p80286]

Verdammt gute Frage, so steht's auch im historischen D7.

Dann würde für "Open" nur sprechen, daß eine (Fremd)Komponente noch etwas zwischen "open" und "active" erledigt.
Oder in Zukunft .....

Gruß
K-H

[TigerLilly]

Open/Close und Active sind gleichwertig. Auch die TFDQuery routet das Open auf Active:=True um.

[Schokohase]

Zitat:

Zitat von p80286 (Beitrag 1447887)

Ich pers. würde Anmerkungen von Markus immmer sehr ernst nehmen. Aber das ist meine ganz pers. Ansicht.

Da wir aber alle Menschen sind und darum systembedingt auch Fehler machen können, ist es wichtig jede Aussage oder Anmerkung auch kritisch zu betrachten und auf Fehler hinzuweisen.

Eine unterwürfige und demütige Haltung ist hier völlig fehl am Platz und hilft niemandem.

Von daher hat @TigerLilly alles richtig gemacht.

[jobo]

Zitat:

Zitat von Hobbycoder (Beitrag 1447878)

..Ursache.
..
Mit ausreicht Kenntnisse über SQLite hätte ich es vielleicht wissen können, aber man kann tatsächlich einen Feldtyp von Text in Real ändern (in diesem Fall ist das versehendlich passiert), und alle Textwerte belieben in der Tabellenspalte vollständig erhalten. Und leider ist mein DB-Viewer so, dass er prompt den Textinhalt anzeigt.
FireDAC aber aufgrund des Fehdtypes konsequent 0 zurückliefert.

Wie gesagt, auf Grund der Tatsache, dass hinter SQLite keine DB-Server steckt, hätte ich auch eher drauf kommen können.

Das hat nichts mit DB-Server oder nicht zu tun. MS Access oder ähnliche Vertreter verhalten sich da nicht wie SQLite, sondern 'wie gewohnt'.
SQLite macht es einfach anders, mit dynamischen Typen, und hat es auch dokumentiert:

Zitat:

.. However, the dynamic typing in SQLite allows it to do things which are not possible in traditional rigidly typed databases.

https://www.sqlite.org/datatype3.html

"..Dinge, die in traditionellen System nicht möglich sind.."
Dazu gehören natürlich auch ungewöhnliche Fehlerkonstellationen.

Es gibt hier schon einige Threads, die auf diesem unerwarteten Verhalten beruhen, also den Auswirkungen dieses dynamic typing. Wenn man mit SQLite arbeitet und im weitesten Sinne Probleme Wertzuweisung und Rückgabe/Darstellung/Abfrage hat, sollte man spätestens an diese Besonderheit denken.

"Lustig", dass gerade in Delph respektive Pascal mit der exakten Typen Ideologie auch diese Schieflage auftritt. Was nochmal im Kontrast dazu steht, dass selbst unter "Delphianern" offenbar intuitiv gern Datumswerte als Text/String bearbeitet werden, um dann mit den Folgen zu kämpfen. Nagut, das ist der "Blinde Fleck" in der Datentypenbrille.

Dynamic Typing von SQLite ist dagegen einfach ein vollkommen ungewohntes "Feature". Ohne die Kenntnis oder Idee seiner Existenz ist es einfach tückisch, besonders in Kombination mit einer irrtümlichen Spaltentypisierung.

[Rollo62]

Zitat:

Zitat von TigerLilly (Beitrag 1447945)

Open/Close und Active sind gleichwertig. Auch die TFDQuery routet das Open auf Active:=True um.

Ich vermute mal das kommt daher das die DB-Komponenten gerne mal Active True/False auch im Designer anbieten.
Deshalb macht es wohl Sinn 2 gleichwertige Wege anzubieten, das macht durchaus Sinn.

[jobo]

An der gezeigten Implementierung kann man nur erkennen, dass "Open" zumindest in der Theorie mehr ist. Besser oder schlechter oder anders wäre vielleicht eine Spekulation auf die Zukunft, in der die Open Methode noch weitere Zeilen enthalten könnte, neben active := true.

Ich könnte mir auch vorstellen, dass die Problematik irgendwie mit

Code:

If dataset.active = true ..

vermischt wird, was jedenfalls nicht so ratsam ist.

Im Sinne von Klarheit und Lesbarkeit stellen Open für Datenmengen und ein Execute für Befehle für mich auch die bessere Alternative dar.

[Schokohase]

Solange wie die Eigenschaft

Delphi-Quellcode:

Active

anzeigt ob die Verbindung aktiv ist (oder eben nicht) und diese Eigenschaft nicht read-only ist, solange wird diese das Gleiche auslösen müssen, wie ein Aufruf von

Delphi-Quellcode:

Open

, wo die Verbindung geöffnet und damit aktiv wird, was dann durch die Eigenschaft

Delphi-Quellcode:

Active

entsprechend angezeigt wird.

[DasWolf]

Ich gehe mal davon aus, dass ein Standard angeboten wird.
Bei

Delphi-Quellcode:

FDQuery1.Open

gibt es ja noch die Möglichkeit, einen SQL-String anzugeben (mit oder ohne Parameter)

Delphi-Quellcode:

FDQuery1.Open('SELECT ID, Bezeichnung FROM Tabelle1 WHERE ID = :ID', [1], [ftInteger]);

.
Wahrscheinlich gibt es deshalb zusätzlich den Standard

Delphi-Quellcode:

Open;

um den Code einheitlich gestalten zu können.