Berechnetes Feld per Code bei nicht persistenter Feldliste

[dataspider]

Hallo,

ich habe eine Query.
Diese erzeuge ich zur Laufzeit, weise alle Parameter zu etc.
Bei dieser Methode ist die Feldliste ja so lange leer, bis ich Active auf True setze.

Ich möchte zusätzlich ein berechnetes Feld hinzufügen.
Mache ich das vor dem Open, habe ich nach dem Open nur ein Feld (nämlich mein im Code erzeugtes), da er die anderen Felder nun nicht mehr erzeugt (Die Feldliste ist ja nicht leer).
Wenn ich das Feld nach dem Open hinzufügen will, beschwert er sich, dass dies bei geöffneter Datenmenge nicht möglich ist.
Kann ich die Query irgendwie dazu bringen, die Feldliste zu erzeugen und mein berechnetes Feld noch anzuhängen?

Danke, Frank

[Hansa]

Warum persistente Felder ? :shock: So kriege ich z.B. 4 Felder in die Datenmenge, davon ein berechnetes :

Code:

SELECT A, B, C, A+B+C AS SUMME from tabelle

[dataspider]

Hi,

die Methode über den Select nützt mir nichts.
Ich habe nach einer Möglichkeit gesucht, eine temporäre Markierung zu setzten.
Ein Beispiel ist die Anzeige mahnungsfähiger Rechnungen. Bevor ich jetzt den Mahnlauf starte, soll der Nutzer die Möglichkeit haben, einzelne Rechnungen aus dem Mahnlauf zu nehmen.
Dafür wollte ich halt ein "editierbares" berechnetes Feld nehmen.
Es funzt auch. Ich kann in meiner Grid mit der Leertaste den Haken entfernen und setzten, also den Status umschalten. Aber vorher muss eben im Designer die Feldliste gefüllt werden, ansonsten hab ich das oben beschriebene Problem.

Aber trotzdem, Danke...

Frank

[daddy]

Ist die Feldliste denn variabel oder immer gleich? Falls letzteres der Fall ist, verfahre ich immer do, dass ich im Query zur Designzeit ebenfalls ein Select mit allen nötigen Feldern formuliere, die dann als persistente Felder übernommen werden können. Solange das neue Select, das später im Quellcode zugewiesen wird, die gleiche Feldliste beinhaltet, gibt es eigentlich keine Probleme.

Gruß Daddy

[dataspider]

Zitat:

Zitat von daddy

Ist die Feldliste denn variabel oder immer gleich?
Gruß Daddy

Danke die erst mal.

Die Feldliste kann sich immer ändern. In meinem Projekt gibt es keine persistenten Felder. SQL-Statement und Alle Parameter liegen in der DB und bis zur Erstellung der Grid läuft alles automatisch. Selbst die Querys, DataSources etc. erstellt mein DataController.
Ich müsste zur Benutzung von persistenten Feldern mein ganzes Framework umbauen.

Was ich aber vergaß zu erwähnen. Ich benutze TIBOQuery, also die TDataSet - kompatible version der IBO's.

Cu, Frank

[alzaimar]

Ich mache es so:

SQL-Code:

Select *, 0 as UserSelectable from MyTable

Ich bekomme eine Tabelle mit allen Feldern der Tabelle und zusätzlich noch eins 'UserSelectable', in dem ich rumwuseln kann (z.B. eine über Checkbox Daten verändern).

Alternativ kannst Du dir zur Laufzeit auch ein Feld erzeugen.

Hier als Beispiel ein TIntegerField. Andere Feldtypen benötigen eventuell weitere Eigenschaften (Size, Precision etc.)

Delphi-Quellcode:

With TIntegerField.Create (MyDataSet) Do Begin
  FieldName := 'AllesWasDuWillst';
  Calculated := False;
  FieldKind := fkData;
  DataSet := MyDataSet;
End;
...
MyDataSet.fieldDefs.update;

[dataspider]

Zitat:

Zitat von alzaimar

Ich bekomme eine Tabelle mit allen Feldern der Tabelle und zusätzlich noch eins 'UserSelectable', in dem ich rumwuseln kann (z.B. eine über Checkbox Daten verändern).

Wenn das ginge, wäre es ja OK.
Aber ich bekomme beim Versuch, dieses UserSelectable Feld zu ändern, immer einen EDataBaseError:
Das Feld blabla kann nicht verändert werden.
Ist ja auch irgendwo logisch, wo soll er das denn hinschreiben.

Oder kennst du einen Trick?

Danke, Frank

[daddy]

Mit was arbeitest Du denn überhaupt? Bei ClientDataSets könnte man z.B. wie von alzaimar vorgeschlagen verfahren. Anschließend kann man die Felder auch ändern (vorausgesetzt man ruft vorher Post und hinterher Edit auf und am besten entfernt man noch pfInUpdate und pfInWhere aus den ProviderFlags).

Edit:
Soory, hab gerade gesehen, die Frage hast Du ja schon in #5 beantwortet.

[alzaimar]

Ach Gott, ja....

Ich verwende ein MemDataset. Dort kopiere ich die Daten vom Server rein (Die Tabelle). Dann kann ich ändern, wie ich lustig bin (die Tabelle hat noch eine weitere Spalte 'Modified'). Beim Klick auf 'OK' werden die geänderten (Feld 'Modified'= True) Zeilen per handgebissenem SQL-INSERT wieder zurück geschrieben.

Das ließe sich mit einem TClientDataset auch machen.

Wie greifst Du drauf zu? Mit ADO? Da kann man den LockType of 'ltBatchOptimistic' setzen, dann ist das soetwas wie 'Cached updates' bei der alten BDE-Krücke. Auf jeden Fall werden die Änderungen nicht sofort zurückgeschrieben. Das erledigst Du mit 'ApplyUpdates'. Dann hättest du wieder das gleiche Problem, aber Du kannst dann selbst durch die Tabelle laufen und die Änderungen wie oben beschrieben (handgebissenes INSERT-Statement :stupid: ) zurückschreiben.

Mittlerweile tendiere ich (außer bei 08/15-Tabellen) sowieso zu dieser (Memdata)Lösung, weil man einfach flexibler ist. Und schneller ist es auch.

Welche DB verwendest Du? Bei MSSQL gibt es 'Updateable Views'. Die kann man mit einem 'INSTEAD OF' Trigger versehen und dann überlistet man quasi ADO/BDE oder wen auch immer.


Hi daddy, guter Vorschlag.

[dataspider]

@alzaimar

Jo, MemDataSet wäre eine durchaus gängige Alternative.

Aber ich habe es jetzt gelöst.
Nach tiefgreifender Wühlerei im Code von IBO musste ich feststellen, dass es in den FieldOptions eine Option foAutoAppendAllFields gibt. Warum ist man manchmal so blind?
Jetzt werden alle Felder erstellt, auch wenn ich vorher ein Feld im Code erzeugt habe.

Danke noch mal an Alle.

Frank