Hallo,
ich versuche gerade einen Umstieg von DBExpress nach UniDac. Dabei sind mir allerdings zwei Eigenarten von UniDac begegnet, welche mich doch an der Komponente zweifeln lassen:
a) Beim Prepare einer
Query wird eine interne Transaktion gestartet.
Bis jetzt habe ich es immer so gemacht, dass ich beim Erzeugen von DBExpress TSQLDataset-Instancen in meinen Model/OPF-Klassen sofort das
SQL-Kommando zuweise und dann die
Query prepariere. Beim Schreiben in der
DB wird dann ggfs. manuell eine Transaktion verwendet. Nun musste ich beim Wechsel nach TUniSQL feststellen, dass bei einem Rollback die Änderungen nicht zurückgenommen wurden.
Nach stundenlangen Suchen bin ich dann dahinter gekommen, dass durch ein Prepare schon eine interne Transaktion gestartet wird, und daher keinen Bezug zur manuellen Transaktion mehr hat. Als ich dann TUniConnection und TUniSQL ein Transaktionsobjekt zugewiesen habe, da wurde bei StartTransaction auch schon gleich gemeckert dass schon eine Transaktion aktiv ist.
Nun gut, das Problem kann ich durch entfernen der Prepare Aufrufe lösen und hoffen dass ich nichts vergessen habe was beim Kunden mit wackligen Netzwerk dann durch ein Server-Rollback die Arbeit von Stunden vernichtet. Nur fragte ich mich, warum bei UniDac eine interne Transaktion nötig ist, und DBExpress komischerweise mit dem verwendeten DevArt Firebird-Treiber ohne diese auskommt.
b) RowsAffected von TUniSQL liefert immer 0 zurück
Bei einer TUniSQL Komponente mit einem einfachen Update-Kommando auf eine existierende ID liefert RowsAffected einfach 0. Beim Suchen im DevArt-Forum bin ich bei einem alten Post von 2009 fündig geworden: die
Query muss dazu prepariert sein. Das kann ich reproduzieren, aber damit habe ich wieder das Problem von a) am Hals.
Also muss ich TUniQuery verwenden (welche das Problem nicht hat), oder bei jeder RowsAffected-Abfrage den Execute-Teil in eine manuelle Transaktion einbettten sofern nicht schon eine aktiv ist (schwierig da ich für DBExpress/UniDac einen Wrapper verwende welches dies in der Execute-Methode als Rückgabewert liefert).
Daher mal die Frage: gibt es sonst noch irgendwelche Fallen bei UniDac? Oder mache ich einfach irgendwas falsch?
Sie scheinen ja schon gut zu sein. Aber sie haben mich halt schon Stunden für die Fehlersuche an ganz falschen Stellen gekostet, da ich z.B. Transaktionen bis jetzt immer unter "funktioniert einfach" verbucht, und daher in Unittests nicht weiter berücksichtigt habe. In der Doku zu Prepare/Prepared steht natürlich nichts zu der Besonderheit und auch für den Fall b) gibt es keinen Hinweis. Gerade hier ärgert mich einfach dass RowsAffected dann nicht einfach -1 zurückliefert oder meinentwegen eine
Exception auslöst und mir damit einen halben Tag Fehlersuche gespart hätte.
Bye,
Norman