Manipulation eines Records in einer FDQuery

[Ykcim]

Zitat:

Alternativ kannst du auch bei der Query CachedUpdates auf True stellen und einfach kein ApplyUpdates aufrufen.

Das hat das Problem leider nicht gelöst,

aber basierend auf Deinem Post https://www.delphipraxis.net/1489948-post9.html in der Vergangenheit, habe ich jetzt so einen Erfolg zu verzeichnen:

Delphi-Quellcode:

         CDMQuery.First;
         MsQuery.First;
         MsQuery.Edit;
         MsQuery.FieldByName('Operator').AsString := CDMQuery.FieldByName('userID').AsString;
         MsQuery.Locate('DEVICE_ID', Machine_ID, []);

Ist das noch halbwegs sauber oder gefummelt?

[Jasocul]

Das ist gefummelt und dürfte auch nicht funktionieren.

Wenn die Query durch das Locate in den Browse-Modus versetzt wird, wird implizit vorher ein Post oder Cancel gemacht.
Das bedeutet, du wirst wieder eine Exception (bei Post) bekommen oder deine Daten werden nicht verändert (Cancel).

[Delphi.Narium]

Wozu sind die beiden da?

Delphi-Quellcode:

CDMQuery.First;
MsQuery.First;

Vorher stehst Du in beiden Querys auf dem benötigten Datensatz.

Dann änderst Du (vermutlich) in beiden Querys den Datensatzzeiger per First, um dann auf jedenfall den ersten Datensatz in MsQuery per Edit zu ändern.

Das erscheint mir nicht zwingend sinnvoll. Bei zwei Querys mit jeweils nur einem Datensatz mag das unschädlich sein, ist dann aber, da nur ein Datensatz vorhanden ist, unsinnig, da der eine Datensatz ja auch zwingend sowohl der erste, als auch der letzte Datensatz ist. In allen anderen Fällen läuft das auf eine Art Zufallsgenerator hinaus. Abgesehen davon steht der Datensatzzeiger nach 'nem Open sowieso auf dem ersten Datensatz. Ein Konstrukt in der Form

Delphi-Quellcode:

CDMQuery.Open;
CDMQuery.First;

bringt schlicht und einfach keinen Vorteil, sondern ist im Zweifel nur sinnfrei.

Per Edit einen Datensatz zu ändern und vor dem Speichern der Änderung den Datensatz per Locate zu ändern, erscheint mir nicht sinnvoll. Je nach Einstellung dürfte das Locate ein Post implizieren oder ein Cancel. Beim Post steht dann die Änderung in einem anderen Datensatz, als in dem per Locate gesuchten und ggfls. angezeigten. Bei einem impliziten Cancel wird keine Änderung durchgeführt. Damit könnte man sich den Änderung auch sparen, da sie beim Locate sowieso verworfen wird.

Lade Dir die benötigten Daten per SQL. Übertrage das Ergebnis in eine MemTable (s. o.) und arbeite dann ausschließlich mit dieser weiter.

Bei deiner bisherigen Anforderungsbeschreibung erscheint mir alles andere als "Gefrickel", sprich: Nicht zielführend und nicht sicher und zuverlässig implementierbar.

Delphi-Quellcode:

                                'CASE WHEN ( '+
                                  'concat(rj.JOB_ID, ' + QuotedStr(' ') + ', JOB_NAME) is NULL) then '+

Was ich ncht verstehe: concat(rj.JOB_ID, ' + QuotedStr(' ') + ', JOB_NAME)
Kann ein concat(Null, ' ', Null) Null sein oder ist es immer zwingend ein ' ' und damit nicht Null?


Ein paar Stunden später:

Was mir noch auffiel:

Per TOP 1 wird ein Datensatz gesucht, die Ergbenismenge enthält also 0 oder 1 Datensatz. Danach wird per First auf den ersten von einem Datensatz gewechselt und dieser eine Datensatz wird dann erfolgreich(?) in diesem einen Datensatz per Locate gesucht.
Das Ergebnis von Locate wird jedoch nicht überprüft, bei false hieße es z. B., dass der eine Datensatz in der Menge von einem Datensatz nicht gefunden wird, aber der dann zufällig beim Datansatzzeiger stehende Datensatz, also der erste und einzige Datensatz, wird zur weiteren Verarbeitung genutzt.

Wenn nun diese Konstrukt so funktioniert und vorhandene Probleme behebt, ist das absoluter Zufall.

Bitte überprüfe dein Vorgehen noch einmal, ggfls. liefere uns eine (möglichst) konkrete Beschreibung der Aufgabenstellung, damit wir zielgerichtete Hilfestellung geben können.

[Ykcim]

Hallo,

vielen Dank für den ausführlichen Post! Ich arbeite nicht oft mit datensensitiven Komponenten, sondern befülle Grids und andere Komponenten meistens von Hand. Auch insert / updates Statements schreibe ich für gewöhnlich manuell und verwende eine Query nur als Schnittstelle zur Datenbank.

Von daher war der Befehl Query.First die Hosenträger zum Gürtel und weil ich testen wollte, ob ich damit irgendwie weiterkomme. Ich bin mir absolut bewusst, dass ich die in diesem Anwendungsfall nicht benötige.

Was will ich gerade machen: Ich habe eine Client / Server App, die den Life-Zustand der Maschinen anzeigt. Dabei laufen mehrere Clients hier im Unternehmen. Diese fordern alle 60 Sekunden neue Daten von der Server App an (also nicht ganz Life).

Wenn aber 5 Clients, die zu unterschiedlichen Uhrzeiten gestartet werden, immer die Daten anfordern, wären das ziemlich viele unnötige Abfragen. Deshalb lasse ich die Server App alle 60 Sekunden die Daten von der DB abfragen, die dann in der Query stehen. Immer wenn ein Client nach frischen Daten fragt, werden diese via Query.SaveToStream an den Client geschickt.
Wenn 120 Sekunden kein Client nach neuen Daten gefragt hat, stoppt auch der Server seine Abfragen und startet erst wieder mit einer neuen Anfrage.

Ich nutze also die Query als Datenspeicher aus dem die Clients bedient werden.

Jetzt habe ich aber leider das Problem, dass die Daten nicht von einem Datenbankserver kommen, sondern von zweien. Das liegt daran, dass das ERP-System so aufgebaut ist, denn die Datenbanken gehören zum ERP-System.

Deshalb habe ich eine zweite Query created, die Daten aus der Tabelle auf dem zweiten Datenbank-Server abgefragt und wollte anschließend ein Datenfeld in der ersten Query durch Daten aus der zweiten Query ersetzen.

Deshalb ist ein Post an der Stelle gar nicht gewünscht, denn ich will gar keine Daten auf der Datenbank ändern, sondern nur den aktuellen Datensatz in der Query. Und dafür brauche ich eine Möglichkeit, den Editiermodus zu beenden.

Ich hatte zwischendurch einen anderen Weg mit einem JSON-Result, welches ich über die API bekommen kann getestet. Hatte dabei dann die Daten manuell in eine FDMemTable geschrieben und versucht, diese via MEMTable.SaveToStream an den Client zu übergeben. Aber dann funktionierte das LoadFromStream leider nicht, weil der Stream nicht interpretiert werden konnte.

Die Lösung, die oben steht, funktioniert bis hierhin ohne Zicken, denn ich habe sie heute den ganzen Vormittag parallel laufen lassen. Aber ich hätte gerne eine saubere Lösung, auch wenn die App für den Eigengebrauch ist...

Vielen Dank und lieben Gruß
Patrick

[Delphi.Narium]

Hm, weiß nicht so recht, ob ich das richtig verstanden habe.

Von einem Server bekommst du sehr viele Daten per SQL. Nun muss du aus einer zweiten Datenbank einen anderen Wert holen und damit ein Feld der ersten Daten ändern.

Das Ergebnis muss nicht gespeichert werden, sondern nur solange im Arbeitsspeicher für die Weitergabe an die Clients zur Verfügung stehen, bis eine bestimmte Zeitspanne abgelaufen ist oder über einen längeren Zeitraum keine Clientanfrage beim Server ankommt.

Grob also sowas:

Delphi-Quellcode:

// In einem Timerereignis oder wie auch immer die "Zeitschleife" gesteuert wird.
begin
  // Cancel und Close funktionieren auch fehlerfrei, wenn die Abfrage weder im Editiermodus noch geöffnet ist.
  MsQuery.Cancel; // Letzte Änderung verwerfen.
  MsQuery.Close; // Letzte Abfrage schließen.
  MsQuery.SQL.Add('große Abfrage von oben'); // Neue Abfragen erstellen.
  CDMQuery.SQL.Add('kleine Abfrage von oben');
  MsQuery.Open; // Erste Abfrage öffnen
  CDMQuery.ParamByName('Device').AsString := MsQuery.FieldByName('device_id').AsString; // und in zweiter Abfrage den Parameter setzen.
  CDMQuery.Open; // Die zweite Abfrage öffnen,
  MsQuery.Edit; // die erste Abfrage editieren und den Wert aus der zweiten Abfrage übernehmen.
  MsQuery.FieldByName('Operator').AsString := CDMQuery.FieldByName('userID').AsString;
  // Die Abfrage bleibt im Editiermodus.
  // Bei Anforderungen durch einen Client müssten dann die bereits editierten, aber nicht gespeicherten Daten,
  // per SaveToStream ausgeliefert werden.
end;

[Delphi.Narium]

Eventuell ginge aber auch sowas:

Delphi-Quellcode:

procedure TMxSQL.Get_act_MachineData(Machine_ID: string; LStream: TStream; RefreshData, SendData: boolean);
...
begin
...
  OperationsList := DB_Modul.Read_Einstellungswert('Life_Data_OperationList');
  MsQuery.SQL.Add('große Abfrage von oben'); // Neue Abfragen erstellen.
  CDMQuery.SQL.Add('kleine Abfrage von oben');
  MsQuery.Open; // Erste Abfrage öffnen
  CDMQuery.ParamByName('Device').AsString := MsQuery.FieldByName('device_id').AsString; // und in zweiter Abfrage den Parameter setzen.
  CDMQuery.Open; // Die zweite Abfrage öffnen,
  MsQuery.Edit; // die erste Abfrage editieren und den Wert aus der zweiten Abfrage übernehmen.
  MsQuery.FieldByName('Operator').AsString := CDMQuery.FieldByName('userID').AsString;
  MsQuery.SaveToStream(LStream, sfJSON); // unmittelbar nach der Änderung in den Stream schreiben,
  MsQuery.Cancel; // die letzte Änderung verwerfen
  MsQuery.Close; // und die Abfragen schließen.
  CDMQuery.Close;
...
end;

Der Stream enthält immer die aktuellen Daten, so dass bei einer Anforderung durch einen Client nicht jedesmal auf die Query zugegriffen werden muss. Der Inhalt des Streams bleibt ja erhalten und kann beliebig oft an die Clients ausgeliefert werden.

Eigentlich wird nur die Stelle, an der die Query in den Stream geschrieben wird, in deiner ursprünglichen Prozedur an eine andere Stelle verschoben. Der Teil ab  if SendData then begin kann (vermutlich) entfallen.

Hoffentlich liege ich damit nicht allzuweit daneben

[Ykcim]

Zitat:

Hoffentlich liege ich damit nicht allzuweit daneben

Damit liegst Du genau richtig. Ich habe es so gelöst, als ich eine Procedure unter Verwendung der API-Schnittstelle gebaut habe:

Delphi-Quellcode:

procedure TMxSQL.Get_act_MachineJSON(Machine_ID: string; RefreshData, SendData: boolean; var LStream: TMemoryStream);
var   Logic: TLogic;
      API_URL: string;
      IdHTTP_MStatus: TIdHTTP;
      RStream: TMemoryStream;
begin
   if (RefreshData = false) and (DB_Modul.Tmr_LM_RefreshData.Enabled = false) and (SendData = true) then begin
      RefreshData := true;
      DB_Modul.Tmr_LM_RefreshData.Enabled := true;
      DB_Modul.FLM_OfflineState := 0;
      DB_Modul.Write_LM_Protokoll('RefreshTimer aktiviert.');
   end;

   if (RefreshData = false) and (DB_Modul.Tmr_LM_RefreshData.Enabled = true) and (SendData = true) then begin
      DB_Modul.Tmr_LM_RefreshData.Enabled := true;
      DB_Modul.FLM_OfflineState := 0;
      DB_Modul.Write_LM_Protokoll('OfflineState-Counter zurückgesetzt.');
   end;
   if (DB_Modul.Tmr_LM_RefreshData.Enabled = false) then begin
      DB_Modul.Tmr_LM_RefreshData.Enabled := true;
      DB_Modul.FLM_OfflineState := 0;
      DB_Modul.Write_LM_Protokoll('RefreshTimer aktiviert. OfflineState-Counter zurückgesetzt.');
   end;
   Logic := TLogic.create;
   IdHTTP_MStatus := TIdHTTP.Create;
   API_URL := DB_Modul.Read_Einstellungswert('MData_API_URL');
   API_URL := API_URL + Machine_ID;

   RStream := TMemoryStream.Create;
   try
      if (RefreshData = true) then begin
         IdHTTP_MStatus.Request.BasicAuthentication := true;
         IdHTTP_MStatus.Request.Username := DB_Modul.Read_Einstellungswert('API_User');
         IdHTTP_MStatus.Request.Password := DB_Modul.Read_Einstellungswert('API_Passwort');
         IdHTTP_MStatus.Get(API_URL, RStream);
         //RStream in den FStream kopieren
         DB_Modul.CopyStream('LStream_',Machine_ID,'', RStream);
         DB_Modul.Write_LM_Protokoll('Refresh Daten Maschine ' + Machine_ID);
      end;
      //FStream in den LStream kopieren
      DB_Modul.CopyStreamBack('LStream_',Machine_ID,'', LStream);
   Finally
      Logic.Free;
      IdHTTP_MStatus.Free;
      RStream.Free;
   end;
end;

Aber ehrlich gesagt, fühlt sich das auch irgendwie gefuckelt an... Schreibe etwas in die Query (es geht nur um ein Feld, was geändert werden muss), speichere in Stream und verwirf die Änderung wieder...

Mal gucken, vielleicht baue ich es noch um, aber jetzt geht es kurzum erst einmal in den Urlaub.

Vielen Dank
LG Patrick

P.S.: Bevor das Fragezeichen aufwirft, ich hatte ziemlich Probleme, dass die Daten irgendwie zerstört wurden (also der Stream), bevor sie an den Client gingen, daher habe ich testweise mit unterschiedlichen Streams gearbeitet und von einem in den nächsten kopiert... Geht mit Sicherheit besser!

[Delphi.Narium]

Habe mal noch ein bisserl rumgefrickelt:

Delphi-Quellcode:

// procedure TMxSQL.Get_act_MachineJSON(Machine_ID: string; RefreshData, SendData: boolean; var LStream: TMemoryStream);
procedure TMxSQL.Get_act_MachineJSON(Machine_ID: string; RefreshData, SendData: boolean; LStream: TMemoryStream);
var Logic: TLogic;
      API_URL: string;
      IdHTTP_MStatus: TIdHTTP;
      RStream: TMemoryStream;
begin
   if (not RefreshData) and (not DB_Modul.Tmr_LM_RefreshData.Enabled) and (SendData) then begin
      RefreshData := true;
      DB_Modul.Tmr_LM_RefreshData.Enabled := true;
      DB_Modul.FLM_OfflineState := 0;
      DB_Modul.Write_LM_Protokoll('RefreshTimer aktiviert.');
   end else
   if (not RefreshData) and (DB_Modul.Tmr_LM_RefreshData.Enabled) and (SendData) then begin
      DB_Modul.Tmr_LM_RefreshData.Enabled := true;
      DB_Modul.FLM_OfflineState := 0;
      DB_Modul.Write_LM_Protokoll('OfflineState-Counter zurückgesetzt.');
   end else
   if (not DB_Modul.Tmr_LM_RefreshData.Enabled) then begin
      DB_Modul.Tmr_LM_RefreshData.Enabled := true;
      DB_Modul.FLM_OfflineState := 0;
      DB_Modul.Write_LM_Protokoll('RefreshTimer aktiviert. OfflineState-Counter zurückgesetzt.');
   end;
   Logic := TLogic.create;
   IdHTTP_MStatus := TIdHTTP.Create;
   API_URL := Format('%s%s',[DB_Modul.Read_Einstellungswert('MData_API_URL'),Machine_ID]);

   RStream := TMemoryStream.Create;
   try
      if (RefreshData) then begin
         IdHTTP_MStatus.Request.BasicAuthentication := true;
         IdHTTP_MStatus.Request.Username := DB_Modul.Read_Einstellungswert('API_User');
         IdHTTP_MStatus.Request.Password := DB_Modul.Read_Einstellungswert('API_Passwort');
         IdHTTP_MStatus.Get(API_URL, RStream);
         //RStream in den FStream kopieren
         DB_Modul.CopyStream('LStream_',Machine_ID,'', RStream);
         DB_Modul.Write_LM_Protokoll(Format('Refresh Daten Maschine %s',[Machine_ID]));
      end;
      //FStream in den LStream kopieren
      DB_Modul.CopyStreamBack('LStream_',Machine_ID,'', LStream);
   Finally
      Logic.Free;
      IdHTTP_MStatus.Free;
      RStream.Free;
   end;
end;

Werden die Daten im Stream auch noch zerstört, wenn Du im Prozeduraufruf das Var vor dem LStream weglässt?