FDQuery CachedUpdates Datensatz speichern?

[HCB]

Hallo, ich habe eine Access Datenbank mit 120 Spalten. Die Datensätze werden in einem dbGrid angezeigt. Soweit so gut.

1.) Ändere ich jetzt eine Spalte und will den Datensatz verlassen, kommt die Fehlermeldung '[FireDac][Phys][ODBC][Microsoft][ODBC-Treiber für Microsoft Access]Abfrage ist zu komplex. Der Datensatz bleibt im Edit-Modus und kann nicht gespeichert werden. Reduzier ich die Spalten um ca. 20 spalten so dass ich nur noch 100 habe, läufts. Gibts da eine Beschränkung???

2.) Stelle ich die Eigenschaft des FDQuery.CachedUpdates auf true, dann kommt keine Fehlermeldung und der Datensatz wird geändert und im dbGrid dementsprechend angezeigt. Soweit so gut.

3.) Bei einem Neustart des Programms werden jedoch wieder die alten Werte angezeigt, die zuvor geänderten Datensätze wurde offenbar nur temporär geändert und nicht in der Datenbank gespeichert. Speichern habe ich mit FDQuery.Post, FDQuery.CommitUpdates, oder mit FDQuery.UpdateRecord probiert. Es werden die Änderungen aber nicht in der Datenbak gespeichert.

Frage: Kann mir jemand helfen das Problem zu lösen? Hat jemand eine Idee woran das liegen könnte?

LG Harry

[Olli73]

iErrors := FDQuery1.ApplyUpdates;

[HCB]

Hallo Olli73,

vielen Dank. Leider wird nur temporär gespeichert. Hier mein code:

procedure TForm1.Button1Click(Sender: TObject);
var iErrors: integer;
begin
if DataSource1.State = dsEdit then
begin
FDConnection1.StartTransaction;
iErrors := FDQuery1.ApplyUpdates;
if iErrors = 0 then
begin
FDQuery1.CommitUpdates;
FDConnection1.Commit;
end;
end;
end;

Beim nächsten Programmstart werden wieder die vorherigen und nicht die aktualisierten Werte gezeigt.
Bei einer anderen Tabelle mit ca. 85 Spalten läufts ohne Probleme. Vielleicht gibt es doch eine Einschränkung mit access oder dem Treiber, Firedac etc.

Vielleicht hat jemand noch eine Idee?
LG Harry

[Delphi.Narium]

Einfach mal die Suchmaschine Deiner Wahl mit Abfrage ist zu komplex füttern.

Der Fehler kommt in vielfältiger Form vor. Eine dieser Formen entspricht Deiner Beobachtung: Zuviel Spalten.

Lösungen dazu: Keine sinnvollen, sondern immer nur: Nimm doch weniger Spalten. Also eigentlich keine Lösung in Sicht, auch wenn sich der Fragezeitraum für dieses Problem schon über gefühlt zwei Jahrzehnte erstreckt.

[Uwe Raabe]

Kannst du mal die Einstellungen für die Query und Felder zeigen? Am besten wäre ein abgespecktes Beispiel.

[HCB]

So wie es jetzt aussieht, muss ich wohl einige Felder löschen. Da das aber eine aktive Datenbank ist, muss ich sehen, ob wirklich alle Felder vom Hauptprogramm (nicht von mir) genutzt werden, so dass ich die überflüssigen Felder löschen kann.

Anbei mal die Test.mdb mit der Tabelle sPersKto wo ein paar Beispieldaten hinterlegt sind, zum Testen.

LG Harry

[Uwe Raabe]

Interessant wären hier wirklich die Einstellungen der FDQuery.

[Uwe Raabe]

Achte darauf, dass in der FDQuery unter UpdateOptions.UpdateMode das upWhereKeyOnly eingetragen ist, und das für das Feld Nummer unter ProviderFlags das pfInKey angehakt ist. Das geht entweder über ein statisches Feld oder dynamisch im AfterOpen.

Es reicht übrigens, wenn Nummer das einzige statische Feld ist. Dazu muss in der Query unter FieldOptions der Wert für AutoCreateMode auf acCombineAlways stehen. Dann werden alle übrigen Felder dynamisch angelegt.

[HCB]

An den Eigenschaften der FDQuery wurde nichts geändert (also nur die Komponente platziert) und als SQL select * from sPersKto hinterlegt. Das ist alles.

[HCB]

upWhereKeyOnly ist eingetragen, AutoCreateMode steht auf acCombineAlways, aber ProviderFlags finde ich nicht.
Geht aber mit den ersten zwei Einstellungen auch nicht.