TFDQuery Select - Ermitteln ob ein Feld Berechnet ist ( Computed Field )

[Emwykey]

Hallo Zusammen,

ich hole per SQL mit einem TFDQuery über Select * From XXX den Inhalt einer Tabelle. Ich möchte die bestehenden Daten in einem neuen Query leicht verändert wieder via Insert als neuen Datensatz speichern. Es soll eine Routine für mehrere verschiedene Tabellen geben, daher möchte ich das ganze variabel programmieren. Ich erstelle aus den mit dem Select gefundenen Daten und der Felderdefinition im TFDQuery also mein Insert Query. Mein Problem ist, dass wenn in einer Tabelle Computed Fields vorhanden sind diese beim Insert natürlich einen Fehler verursachen. Wie kann ich über die Felder aus meinem Select Query oder die Felderdefinition ermitteln, ob es sich um ein Berechnetes Feld handelt oder nicht?
Die Optionen ReadOnly und FieldKind funktionieren bei mir leider nicht ( ReadOnly ist immer false, FieldKind immer fkData ).
Ich erstelle das Query per Create, ordne die Connection zu, schreibe den SQL in den SQL Text und öffne die Daten mit Open. Muss ich vielleicht noch einen weiteren Schritt machen, damit mir der FieldKind korrekt angezeigt wird? Oder suche ich ganz an der falschen Stelle?

Edit: Die Variable Calculated ist ebenfalls false

Lieben Dank im Voraus!

[Delphi.Narium]

Zitat:

Zitat von Delphi 7-Hilfe

InternalCalcField (Eigenschaft von TFieldDef)

property InternalCalcField: Boolean;

Also z. B.:

Delphi-Quellcode:

for i := 0 to TFDQuery.FieldCount - 1 do begin
  if TFDQuery.Fields[i].InternalCalcField then begin
    // berechnete Logik
  end else begin
    // unberechenbare Logik
  end; 
end;

[Emwykey]

Hallo, danke für die Antwort, die Eigenschaft ist leider auch false :(

hier mal ein Code Ausschnitt, vielleicht fällt ja noch was auf:

Code:

  QuCloneData := TFDQuery.Create( nil );
  QuCloneData.Connection := fConnection;
  QuCloneData.Sql.Text := 'Select * from !Tabelle ';
  QuCloneData.MacroByName( 'Tabelle' ).AsRaw := fTableName;
  QuCloneData.Open;

  for i := 0 to QuCloneData.Fields.Count-1 do begin
    if ((  not QuCloneData.FieldDefs[i].InternalCalcField  )
    and ( AnsiUpperCase(QuCloneData.Fields[i].FieldName) <> AnsiUpperCase( fKeyFieldName ) )) then begin
      if Trim( FieldString ) <> '' then begin
        FieldString := FieldString + ',';
        ParamString := ParamString + ',';
      end;
      FieldString := FieldString + QuCloneData.Fields[i].FieldName;
      ParamString := ParamString + ':' + QuCloneData.Fields[i].FieldName;
    end;
  end;

[Delphi.Narium]

Und was verbirgt sich hinter !Tabelle?

Mal ein Createstatement, damit man 'nen Vorstellung davon bekommt, was gemeint sein könnte?

[Sherlock]

Quark, kann weg.

Sorry

Sherlock

[Frickler]

Berechnete Felder in TDataSet und berechnete Felder in der Datenbank sind zwei verschiedene Paar Schuhe:
- Berechnete Felder in TDataSet sind lokal berechnet, d.h. mittels einer OnCalcField Methode, etwa für eine spezielle Darstellung in einem Grid o.ä.
- Berechnete Felder in der Datenbank ("Computed By") sind hingegen auf dem Server berechnet.
Jede Datenbank hat spezielle Tabellen oder Views für Informationen über die Datenbankstruktur selbst. Dort musst Du nach den Tabellenfeldern suchen und nachschauen, ob diese berechnet sind.

[Emwykey]

Zitat:

Zitat von Frickler (Beitrag 1426451)

Berechnete Felder in TDataSet und berechnete Felder in der Datenbank sind zwei verschiedene Paar Schuhe:
- Berechnete Felder in TDataSet sind lokal berechnet, d.h. mittels einer OnCalcField Methode, etwa für eine spezielle Darstellung in einem Grid o.ä.
- Berechnete Felder in der Datenbank ("Computed By") sind hingegen auf dem Server berechnet.
Jede Datenbank hat spezielle Tabellen oder Views für Informationen über die Datenbankstruktur selbst. Dort musst Du nach den Tabellenfeldern suchen und nachschauen, ob diese berechnet sind.

Ja, das ist mir bekannt, hab es zwischenzeitlich auch so gelöst, ich fänd es aber dennoch klasse wenn es eine Option direkt über das Dataset gäbe ohne die Systemtabellen händisch abfragen zu müssen. Wenn also jemand noch was einfällt immer her damit :-D

[Emwykey]

Zitat:

Zitat von Delphi.Narium (Beitrag 1426448)

Und was verbirgt sich hinter !Tabelle?

Mal ein Createstatement, damit man 'nen Vorstellung davon bekommt, was gemeint sein könnte?

Dahinter verbirgt sich der Name einer Tabelle, die an die Funktion übergeben wird, da die Funktion dann für viele verschiedene Tabellen aufgerufen wird. Das wird dann mit der Funktion MacroByName( 'Tabelle' ).AsRaw := fTableName komplettiert ;)

[Emwykey]

Zitat:

Zitat von Sherlock (Beitrag 1426450)

Quark, kann weg.

Sorry

Sherlock

muss ich das jetzt verstehen?

[Union]

Lässt Du von FireDAC die Metadaten einlesen?

[Emwykey]

Zitat:

Zitat von Union (Beitrag 1426456)

Lässt Du von FireDAC die Metadaten einlesen?

Vermutlich nicht .. das sagt mir grad zumindest nichts, wie geht das denn?

[Union]

Delphi-Quellcode:

TFDConnection1.Params.Add('ExtendedMetaData=True');

[Delphi.Narium]

Zitat:

Zitat von Emwykey (Beitrag 1426453)

Zitat:

Zitat von Delphi.Narium (Beitrag 1426448)

Und was verbirgt sich hinter !Tabelle?

Mal ein Createstatement, damit man 'nen Vorstellung davon bekommt, was gemeint sein könnte?

Dahinter verbirgt sich der Name einer Tabelle, die an die Funktion übergeben wird, da die Funktion dann für viele verschiedene Tabellen aufgerufen wird. Das wird dann mit der Funktion MacroByName( 'Tabelle' ).AsRaw := fTableName komplettiert ;)

Das ist wohl absolut klar.

Mich interessiert ein Createstatement so einer Tabelle, damit man eine Vorstellung davon bekommt, wie die berechneten Felder datenbanksseitig entstehen, um ausgehend von einer konkret existierenden Tabelle Rückschlüsse auf eine allgemeingültige Regel ziehen zu können.

[Sherlock]

Zitat:

Zitat von Emwykey (Beitrag 1426454)

Zitat:

Zitat von Sherlock (Beitrag 1426450)

Quark, kann weg.

Sorry

Sherlock

muss ich das jetzt verstehen?

Neee, aber vielleicht ein Moderator ;-)

[Emwykey]

Zitat:

Zitat von Delphi.Narium (Beitrag 1426460)

Zitat:

Zitat von Emwykey (Beitrag 1426453)

Zitat:

Zitat von Delphi.Narium (Beitrag 1426448)

Und was verbirgt sich hinter !Tabelle?

Mal ein Createstatement, damit man 'nen Vorstellung davon bekommt, was gemeint sein könnte?

Dahinter verbirgt sich der Name einer Tabelle, die an die Funktion übergeben wird, da die Funktion dann für viele verschiedene Tabellen aufgerufen wird. Das wird dann mit der Funktion MacroByName( 'Tabelle' ).AsRaw := fTableName komplettiert ;)

Das ist wohl absolut klar.

Mich interessiert ein Createstatement so einer Tabelle, damit man eine Vorstellung davon bekommt, wie die berechneten Felder datenbanksseitig entstehen, um ausgehend von einer konkret existierenden Tabelle Rückschlüsse auf eine allgemeingültige Regel ziehen zu können.

Aah mein Fehler, sorry :-D


ein Konkretes beispiel kann ich dir leider nicht geben aber eines der Felder ist zum Beispiel so erstellet:

Code:

ALTER TABLE TABELLE1 ADD  FELD1 Integer 
COMPUTED BY 
(
IIF( TABELLE1.FELD1 <> 0, 
     TABELLE1.FELD1, 
     ( Select 
       TABELLE2.FELD1 
       FROM TABELLE2
       WHERE TABELLE2.FELD2 = TABELLE1.FELD2
     )
  ) 
)

[Delphi.Narium]

Tabelle1 und Feld1 sind dann wohl mal Beispiele.

Wenn es über die Metadaten nicht gehen sollte, habt ihr irgendwelche Namenskonventionen? Auch wenn das nicht unbedingt sehr schön ist, aber darüber ließe sich das dann eventuell lösen.

[hoika]

Hallo,
aus der Query selbst kannst Du das nicht bestimmen.

CalcField und InternalCalcField funktionieren wohl nur bei ClientDataSets
https://www.delphipraxis.net/171017-...calcfield.html

[Union]

Aber Readonly bzw. not CanModify sollte es doch wohl sein?

Zitat:

Zitat von Microsoft Doc

Eine berechnete Spalte kann nicht das Ziel einer INSERT- oder UPDATE-Anweisung sein.

[hoika]

Hallo,
warum sollte es das (ReadOnly).

Das würde ja heißen, dass die Query ja die DB fragen muss.
Das kostet doch extra und i.d.R. will ich das ja gar nicht wissen.

[p80286]

Zitat:

Zitat von Union (Beitrag 1426471)

Aber Readonly bzw. not CanModify sollte es doch wohl sein?

Zitat:

Zitat von Microsoft Doc

Eine berechnete Spalte kann nicht das Ziel einer INSERT- oder UPDATE-Anweisung sein.

Und was ist mit den "nicht updatefähigen Views"? Gut man könnte das auch als "berechnet" ansehen...

Gruß
K-H

[hoika]

Hallo,

Zitat:

"nicht updatefähigen Views"

Das weiss Firebird, aber nicht du.

Ab das Ergebnis einer Abfrage aus einem View, SP, external table oder direkter Query kommt,
muss dem Ergebnis-Abholer doch erst mal egal ein.

Gerade View vs. Table ist doch wichtig, dass das beim Abfrager egal ist.