FireDAC, onDemand, DeadLock

[haentschman]

Danke... 8-)
...dann wühle ich mich mal durch.

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1406758)

Ich bräuchte eine funktionierende Konstellation in Stichpunkten:
1. Server mit Einstellung Blubb
2. Connection mit Einstellung Bla
3. Was ist bei den Querys zu beachten
4. Wie verhalten sich INSERTS die direkt in die Tabelle schreiben
... usw. :wink:

Wenigstens hast Du schon mal die richtigen Prioritäten.
wobei ich 2 und 3 tauschen würde. An der Connection drehen ist schon eher Finetuning.
Was ist der Hintergrund von 4?

Das ist eher unter 1 zu erledigen, weil das ist Job der DB.
Was meinst Du mit "die direkt in die Tabelle schreiben"? Das is eigentlich das Standardverhalten!?

Gruß
K-H

[haentschman]

Moin...:P

Zitat:

Was meinst Du mit "die direkt in die Tabelle schreiben"?

...war komisch ausgedrückt. :wink:
Ich meinte:
Im Moment arbeiten die Querys mit DataSet Methoden...INSERT, EDIT usw. Ich bin dazu übergegangen u.a. auch UPDATE, SELECT Statements direkt über SQL abzusetzen. Das kollidiert aber u.U. mit dem Schreiben einer offenen Query mit der "gleichen" Datenmenge. :gruebel:
Die Frage war eher...kommen sich die Querys in Gehege?

[jobo]

"Gehege"
Neulich hatten wir das Thema Lock Escalation by SQLServer, weiß nicht mehr wo. Das Lock Verhalten ist (ohne Anspruch auf Allgemeingültigkeit) bei dem Produkt traditionell nicht so gut, über die Jahre/Versionen aber besser geworden. Rowlevel locking war langezeit auf der Wunschliste, geht jetzt, kann aber trotzdem mal Aussetzen, eben im Falle einer "Escalation". Was man im Betrieb mit hoher Serverlast übersetzen kann.

Es ist also nicht nur eine Frage der Anwendung und deren Zugriffstechnik. Ich mag das Produkt nicht, deswegen kann ich nicht wirklich konkrete Tipps geben. Würde aber mal testen, ob das Verhalten Last abhängig ist. Z.B. morgens um 8-10 schlecht, 17 uhr und später eben besser. Oder tritt es mit einer einzigen, aktiven Anwendung auf (Die Anwendung sperrt sich tatsächlich selbst)

Auch gern problematisch und ggF. auch bei fettem Code systematisch und relativ zügig zu bereinigen (Trotzdem Fleißarbeit). Commit-Durcheinander.
Ich habe mit Delphi immer mit impliziten Transaktionen gearbeitet und alles was explizites Transaktionshandling macht, verboten, rausgeworfen. Ganz früher auch mal anders und sofort graue Haare bekommen (das war auch ein MS SQL Server).

[p80286]

Wenn möglich das Dataset/SQL Mischmasch beenden.
Nachdem ich mir die Ausführungen von Bernhard zu ADO zu Gemüte geführt habe (ist auch schon Jahre her) hab ich ganz schnell auf ein Datamodule mit SQL-Queries umgestellt. Es reicht wenn ein Chaot vor der Tastatur sitzt, da braucht's nicht noch jemanden, der alles besser wußte.
(Daß damit der Speicherverbrauch sank und die Geschwindigkeit anstieg war ein angenehmer Nebeneffekt, aber Du bist dann wirklich für alles verantwortlich)

Gruß
K-H