Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi FireDAC Commit Problem (https://www.delphipraxis.net/182207-firedac-commit-problem.html)

Uwe Raabe 9. Okt 2014 15:42

AW: FireDAC Commit Problem
 
Das geht natürlich auch in FireDAC genauso.

Aber warum eigentlich so kompliziert? Die TADConnection/TFDConnection bietet doch direkt eine Methode ExecSQL an - auf Wunsch auch mit Parametern. Damit erübrigt sich doch deine eigene Routine.

Eppos 9. Okt 2014 16:05

AW: FireDAC Commit Problem
 
@Uwe Raabe
Ich habe es auch direkt über den ExecSQL in der Connection versucht, nach dem ExecSQL habe ich den Commit aufgerufen gleiches Problem wieder

Welches Isolation sollte man für ein Multiusersystem wählen?

mkinzler 9. Okt 2014 16:12

AW: FireDAC Commit Problem
 
Zitat:

Welches Isolation sollte man für ein Multiusersystem wählen?
ReadCommited

Uwe Raabe 9. Okt 2014 16:18

AW: FireDAC Commit Problem
 
Zitat:

Zitat von Eppos (Beitrag 1275438)
Ich habe es auch direkt über den ExecSQL in der Connection versucht, nach dem ExecSQL habe ich den Commit aufgerufen gleiches Problem wieder

Der explizite Aufruf von Commit ist schon verdächtig und sollte eigentlich gar nicht nötig sein bzw. ist sogar eher schädlich. Insbesondere da offenbar vorher keine Transaktion begonnen wurde.

Eppos 9. Okt 2014 16:33

AW: FireDAC Commit Problem
 
Ich habe Vermutungen...

1. Delphi XE2 Pro. mit AnyDAC hat ein Fehler
2. Delphi XE2 Pro. mit AnyDAC und übers Netzwerk hat ein Problem (Ich glaube gelesen zu haben das das mit der Pro nicht geht)

Weis da jemand was?

mkinzler 9. Okt 2014 16:37

AW: FireDAC Commit Problem
 
Die Beschränkung der Pro bezieht sich auf die mitgelieferten dbExpress-Treiber. Mit anderen Fremdomponenten, was AnyDAC ja war ( hat sich mit Integration als FireDAC geänder) tritt diese Beschränkung nicht auf.

Eppos 12. Okt 2014 22:09

AW: FireDAC Commit Problem
 
Also mit "commitretaining" geht alles... komisch

hstreicher 13. Okt 2014 07:31

AW: FireDAC Commit Problem
 
Commitretaining ist wie ein Schneepflug ,
du schiebst immer mehr Arbeit vor dir her und hast dann irgenwann soviel auf der Schaufel dass nichts mehr vorwärts geht.

Ich empfehle sich mal gründlich in die Verwendung von Transactionen einzulesen/einzuarbeiten.
wenn man das beim Programmdesign am Singleuser Entwickler Arbeitsplatz falsch macht merkt mans nicht
kann man die Produktiven Arbeitsplätze ganz gewaltig ausbremsen

Zu Mkinzlers Antwort dass in einem Multiuser System
Read Commited immer die richtige Auswahl ist , nein das ist falsch
Read Commited ist meist eine gute Wahl,
aber auch die anderen "Isolation Levels" haben Ihre Existenzberechtigung.

jobo 13. Okt 2014 09:43

AW: FireDAC Commit Problem
 
Wie sieht es aus, wenn Du das explizite Commit weglässt?
Würde ich jedenfalls empfehlen, ebenso wie ReadCommitted.
Es mag Sonderfälle geben, wo das sinnvoll oder unvermeidbar ist, aber 99%-100% einer Standardanwendung brauchen das nicht.
Wenn es gebraucht wird, sollte man genau wissen, was man tut.

Explizites Commit kannst Du natürlich nicht einfach weglassen, wenn Du im Client auch explizit Transaktionen beginnst. Dann- nur dann- ist ein fehlendes Commit schlecht. An der Stelle würde ich gründlich prüfen, ob die selbst gestarteten Transaktionen notwendig sind und sie im Zweifel entfernen. Prinzip: Keine Transaktionsverwaltung im Client.

mkinzler 13. Okt 2014 10:10

AW: FireDAC Commit Problem
 
Interessnat ist, das sein Programm am Anfang, genau das gemacht hat: sich auf das autocommit verlassen.

Den Scheiß mit der expliziten Transaktionssteuerung kam von mir.

Aber ich sehe langsam ein, daß ich keine Ahnung von nix habe und ziehe meinen Vorschlag zurück.


Alle Zeitangaben in WEZ +1. Es ist jetzt 07:18 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz