FireDAC, cxGrid, Refresh schägt fehl

[haentschman]

Hallöle...8-)

Ich komme wieder mal mit ausergewöhnlichen Sachen...:oops: Ich hoffe auf Ansatzpunkte. :wink:

Gegeben:
EINE Exe die auf den Server liegt und von den Clienten gestartet wird.


Native Client unterschiedlich auf den Workstations installiert:
2012
2008
2008 + 2012

SOLL:
Wenn ich einer Workstation einen Datensatz anlege, dann soll er auf der anderen Workstation, nach Refresh, angezeigt werden. :thumb:

Problem:
Wenn ich einer Workstation einen Datensatz anlege, steht er nach dem Post in der DB.
Auf verschieden Workstations wird das Refresh einfach ignoriert... wie immer auf dem Entwicklungsrechner nicht! :shock:
Bei anderen Grids kommt es manchmal vor, das beim Eintragen eines Wertes und dem anschießenden OnChange, das der Lookup Wert aus einer anderen Tabelle nicht korrekt geholt wird. Die Datenmenge wird über Dataset.Locate durchsucht. Es scheint das die Locate Datenmenge immer auf dem selben Datensatz steht.
...Wenn die Anwendung wieder neu gestartet wird, sind alle Werte korrekt in den Grids vorhanden. :shock:

Refresh:

Delphi-Quellcode:

cxGrid.DataController.RefreshExternalData;

...wird zwar fehlerfrei ausgeführt, aber das Grid interessiert das nicht. Über den Refresh Button im Grid Navigator funktioniert es. (was ich gesehen habe)

...Ideen?

[HolgerX]

Hmm..

Hat den der MS SQL-Server überhaupt (nutzbare) Events?

Nicht jedes Datenbankssystem kann so etwas.

Es sollte dann auch egal sein, welche DB-Komponenten verwendet werden, denn wenn die Datenbank so was nicht hat, kann auch in der Komponente kein Event zum Refreshen ausgelöst werden.

Somit bliebe nur ein Timer, welcher den Query immer wieder schließt und öffnet.
Ich glaube, das ein Query.Refresh nur die bereits vorhandenen Datensätze aktualisiert (wenn sich dort was geändert hat), jedoch nicht neue holt.

So ist es zu mindestens bei ADO.. (wenn ich mich richtig erinnere..)

[haentschman]

Danke...
Die Software ist die gleiche...und das hat immer funktioniert! Wir sind mit der DB nur auf einen anderen Server umgezogen. Neue Installation (Standard Instanz 2017). Kann das damit zusammenhängen?

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1424936)

Wir sind mit der DB nur auf einen anderen Server umgezogen. Neue Installation (Standard Instanz 2017). Kann das damit zusammenhängen?

Wenn das nur wirklich stimmt, würde ich da auch bei der Fehlersuche ansetzen.

[MichaelT]

Zuvor hat was heute Probleme macht immer funktioniert?

Du verwendest die selben Nativeclients wie zuvor? Auch dort lauert allgemein, losgelöst von diesem Fall, ein wenig ein Potential das Ungemach reproduzierbar im Einzelfall kann bereiten. Dann aber konsistent über alle Anwendungen.

Der Datensatz ist tatsächlich committed?
Und trotzdem ist der neu eingefügte Satz mit DataSet Close und Open nicht sichtbar?


a) Schauen ob der Datensatz mit Dataset Close und Open tatsächlich sichtbar ist und
b) Muss man sich die Settings der Grids und Views anschauen.

Zitat:

Zitat von haentschman (Beitrag 1424936)

Danke...
Die Software ist die gleiche...und das immer funktioniert! Wir sind mit der DB nur auf einen anderen Server umgezogen. Neue Installation (Standard Instanz 2017). Kann das damit zusammenhängen?

[haentschman]

Neuigkeiten:
Wir sind mit der DB wieder auf den alten Server 2012 umgezogen. (noch nicht live aber mit der gleichen Konstellation).
...das Refresh Problem, mit 2 getrennten Workstations, ist nicht mehr an dieser Stelle aufgetaucht. Die Daten werden richtig neu eingelesen.

Das Dataset.Locate macht immer noch Probleme...:?

Zitat:

a) Schauen ob der Datensatz mit Dataset Close und Open tatsächlich sichtbar ist und
b) Muss man sich die Settings der Grids und Views anschauen.

..so war es. Die Daten lagen nach dem Post in der DB...aber mit Refresh wurden sie nicht abgeholt.

Ich tippe auch inzwischen auf eine Einstellung des SQL Servers. Welche kämen da in Frage?

Zitat:

Wenn das nur wirklich stimmt

...:lol:

[haentschman]

Was zum grübeln...:gruebel:

[Locate]
Ich konnte das im Screenshot festhalten.
1. Das Locate kommt TRUE zurück (in diesem Falle ist der Suchbegriff "R422D")
2. Der Wert aus der Tabelle wird mit 0 ausgegeben (sollte 2729 sein)
-> kein Wert in der Tabelle hat den Wert 0 (Original NULL) :shock:
-> Wert auf -1 geändert, weil ich denke, das der den letzten Datensatz zurückgibt. (Locate sollte aber dann eigentlich False sein)

...ich habe die Anwendung neu gestartet, alles arbeitet wie erwartet. :evil:

...jetzt kommt ihr. :zwinker:

[MichaelT]

Dann wurde der Datenstand mit dem Ende der Transaktion vermutlich committed, wenn du den Wert nach dem Neustart der Applikation richtig siehst.

Handelt es sich möglw. um ein Ungemach aus dem Eck Transaktion und früher Autocommit?

Ich vermute du arbeitest mit einer Query.

Wenn du mit Post den Satz schreibst dann sieht deine Transaktion zwar den neuen Satz aber alle anderen prinzipiell mal nicht. Das brauche ich dir so mal nicht erzählen.


---

Ich bin ReadCommitted (Oracle).

Beim SQL Server gibt es seit 2005 eine Schraube für eine art Archivelog Mode. Die Sperren beim SQL Server waren mir schon immer suspekt. Das kann man alles zentral konfigurieren. Mit SQL Server habe ich schon lange nichts mehr gemacht. Deswegen traue ich mir auf die Entfernung nicht gut zu raten.

---

NULL und 0 ist ein denke ich ein anderes Thema. Hast du in einer Field Definition eine DefaultExpression definiert?

Zitat:

Zitat von haentschman (Beitrag 1425033)

Was zum grübeln...:gruebel:

[Locate]
Ich konnte das im Screenshot festhalten.
1. Das Locate kommt TRUE zurück (in diesem Falle ist der Suchbegriff "R422D")
2. Der Wert aus der Tabelle wird mit 0 ausgegeben (sollte 2729 sein)
-> kein Wert in der Tabelle hat den Wert 0 (Original NULL) :shock:
-> Wert auf -1 geändert, weil ich denke, das der den letzten Datensatz zurückgibt. (Locate sollte aber dann eigentlich False sein)

...ich habe die Anwendung neu gestartet, alles arbeitet wie erwartet. :evil:

...jetzt kommt ihr. :zwinker:

[haentschman]

8-) Du denkst schon wieder zu weit...
Die Tabelle wo das Locate drauf ausgeführt wird ist eine (sinngemäß) READONLY Table. Das stehen nur Vorgaben drin. Da gibt es kein Commit. Der Datensatzzeiger steht nicht da wo er hin soll...sondern immer auf dem Datensatz 15. Nach einem Neustart der Anwendung wird das Locate anstandslos ausgeführt...nur wie lange.:evil:

PS: Ich tausche das Locate durch ein "Gib mir mal den Datensatz" SQL aus. :zwinker:

Das hat nix mit dem Refresh Problem zu tun. (Ich hätte das lieber in seperate Threads gemacht :oops:)

Zitat:

NULL und 0 ist ein denke ich ein anderes Thema

...imho ergibt .FieldByName('Blubb').AsInteger bei NULL eine 0 :gruebel:

[MichaelT]

So in die Richtung?

Der Beitrag wäre spezifisch zu FireDAC.

Bei Devexpress gibt es Myriaden von Anfragen die in diese Richtung gehen.

Beispiel

--

Ich dachte jetzt an ein Delphi TField mit Bezug auf die DefaultExpression.

Zitat:

Zitat von haentschman (Beitrag 1425056)

8-) Du denkst schon wieder zu weit...
Die Tabelle wo das Locate drauf ausgeführt wird ist eine (sinngemäß) READONLY Table. Das stehen nur Vorgaben drin. Da gibt es kein Commit. Der Datensatzzeiger steht nicht da wo er hin soll...sondern immer auf dem Datensatz 15. Nach einem Neustart der Anwendung wird das Locate anstandslos ausgeführt...nur wie lange.:evil:

PS: Ich tausche das Locate durch ein "Gib mir mal den Datensatz" SQL aus. :zwinker:

Das hat nix mit dem Refresh Problem zu tun. (Ich hätte das lieber in seperate Threads gemacht :oops:)

Zitat:

NULL und 0 ist ein denke ich ein anderes Thema

...imho ergibt .FieldByName('Blubb').AsInteger bei NULL eine 0 :gruebel: