FireDAC: Verhalten von Params

[ioster]

Moin,

ich habe ein Verständnisproblem mit der Art und Weise, wie eine FDQuery die Übergabe von Parametern abwickelt. Hintergrund ist im Augenblick eine Druckroutine, die von einer Stammverwaltung als auch aus einem Beleg aufgerufen werden kann.

Probleme treten nun auf, wenn man den Druck nacheinander über Kreuz aufruft. Dann ist der Parameter, der für die Eingrenzung des Stammdatensatzes benötigt wird, nämlich schon gefüllt und ein neuer Wert wird ignoriert.

Bevor ich den Druck anstoße, schließe ich jedoch die Abfrage und setze den kompletten Abfrageinhalt mit CLEAR zurück. Anschließend wird die Abfrage neu aufgebaut. Parameter übergebe ich mit Parambyname, sofern der Wert nicht aus einer referenzierenden Datenquelle geholt werden soll. In dem Fall reicht die Definition eines Params mit ":" im SQL-Statement.

Jetzt wundere ich mich aber über die Verwaltung der Parameterwerte, denn es macht einen Unterschied, ob ich den Wert über Parambyname übergebe oder im SQL-Statement als Wert mit versenke.

Normalerweise würde ich es so formulieren:

Delphi-Quellcode:

  with Druckmodul.QrMaschine Do
    begin
      Close;
      SQL.Clear;
      SQL.Add('SELECT * FROM MASCHINEN M');
      SQL.Add('WHERE (M.MaschinenNr = :Maschinennr)');
      Parambyname('Maschinennr').AsString := ParamRef;
      Open;
    end;

Dabei wird ParamRef als Wert an die Parameter an die Prozedur übergeben und der Wert entspricht auch dem gewünschten Datensatz.

Wenn ich aber vorab z.B. Maschine 1234 über die Stammdatenverwaltung aufgerufen habe und anschließend aus dem Beleg Maschine 3676 ausgegeben haben möchte, bekomme ich 1234 ausgegeben, obwohl ParamRef 3676 als Wert enthält.

Es ist etwas anderes, wenn ich den Wert so in das Statement einbeziehe:

Delphi-Quellcode:

  with Druckmodul.QrMaschine Do
    begin
      Close;
      SQL.Clear;
      SQL.Add('SELECT * FROM MASCHINEN M');
      SQL.Add('WHERE (M.MaschinenNr = ' + QuotedStr(ParamRef) + ')');
      Open;
    end;

Ich weiß wirklich nicht, was ich davon halten soll. Jeder hat seinen Programmierstil irgendwann gefunden, um mit wenig Aufwand sein Ziel erreichen zu können und trotzdem einen lesbaren Quellcode zu haben. Mein Geschmack ist das Einflechten des Wertes in das SQL-Statement nicht. Vor allem muss auch jedes Mal bei einem String ein QuotedStr oder AnsiQuotedStr um den Ausdruck gesetzt werden.

Kann mir einer verraten, warum das so ist und wie man das Problem lösen kann?

Viele Grüße
Ingo

[Klaus01]

Delphi-Quellcode:

  with Druckmodul.QrMaschine Do
    begin
      Close;
      SQL.Clear;
      SQL.Add('SELECT * FROM MASCHINEN M');
      SQL.Add('WHERE (M.MaschinenNr = :Maschinennr)');
      Parambyname('Maschinennr').AsString := ParamRef;
      Prepare;
      Open;
    end;

vielleicht hilft ein Prepare.

Grüße
Klaus

[ioster]

Zitat:

Zitat von Klaus01 (Beitrag 1481761)

Delphi-Quellcode:

  with Druckmodul.QrMaschine Do
    begin
      Close;
      SQL.Clear;
      SQL.Add('SELECT * FROM MASCHINEN M');
      SQL.Add('WHERE (M.MaschinenNr = :Maschinennr)');
      Parambyname('Maschinennr').AsString := ParamRef;
      Prepare;
      Open;
    end;

vielleicht hilft ein Prepare.

Grüße
Klaus

Danke für Deine Rückantwort. Ich meine, den Auslöser für das merkwürdige Verhalten gefunden zu haben. In der Sequenz, die aus den Stammdaten aufgerufen wird, bekommt die Abfrage die Datasource des Stammsatzes als Referenz zugewiesen. Diese Referenz ist noch so lange aktiv bis die Tabelle geschlossen oder das Fenster eliminiert wird. CLOSE und CLEAR schließen und löschen zwar die Abfrage, aber die neue Abfrage versucht dann trotzdem als erstes mit der Datasource nach Referenzwerten zu suchen. Parambyname geht so ins Leere. Kann ich sogar verstehen, dass die Datasource Priorität hat, wenn sie den Feldnamen enthält.

Wenn man mit dem Problem konfrontiert wird, versteht man aber die Welt irgendwie nicht.

Viele Grüße
Ingo

[mkinzler]

Änderungen sind vor dem Abschließen einer Transaktion ausserhalb dieser nicht sichtbar (wenn man keinen "dirty-read" verwendet).