Hallo Henry, was tust Du denn da Merkwürdiges?! - Wenn Du das Command mit der CreateCommand-Methode erzeugst, ist die Connection schon drin, die musst Du nicht mehr zuweisen. - Es ist sinnlos, einen SELECT mit ExecuteNonQuery auszuführen. Du möchtest ja Ergebnisdaten bekommen, und die kriegst Du nur mit ExecuteReader oder ExecuteScalar(). Mehr dazu weiter unten. - Beim 2. cmd.ExecuteNonQuery(); stützt das Programm ab - was stützt es denn? 😉 Aber wenn es abstürzt, dann verrate uns bloß nicht, wie. Sonst könnte man ja auf eine Idee kommen, was los ist. Mein Versuch, einen Absturz an dieser Stelle mit einem Spielprogramm nachzuvollziehen (.net Core 8, C# 12, MySqlConnection gegen MariaDB 10.6), gelingt nicht. - Kreative Einrückung macht das Lesen von Code spannend. Ich habe eine Weile gebraucht, um festzustellen, dass dein cmd.ExecuteReader() **außerhalb** des catch steht. - Der ExecuteReader ist sinnlos. Zum einen sehe ich keinen rdr.Read(), und zum anderen ist der CommandText in diesem Moment ein DELETE-Statement, das kein Resultset liefert. Aber er wirft keine Exception, soweit ich das erkennen kann. - Du machst im Fehlerfall einen Rollback, im Erfolgsfall aber keinen Commit! Das musst Du definitiv tun, sonst wird die DB nicht verändert und Du kannst auch keinen weiteren BeginTransaction() aufrufen (weil ja schon eine offen ist). - Dass Du vor dem DELETE keinen SELECT machen musst, haben wir Dir schon gesagt. Der DELETE tut einfach nichts, wenn die WHERE-Bedingung nicht erfüllt ist, und du fängst mit dem SELECT ja auch nichts an, du lässt ihn einfach laufen ohne das Resultset abzuholen. Ich hatte schon gedacht, dass er darüber abstürzt, dass es ein schwebendes Resultset gibt - aber nein, war nicht so, gerade ausprobiert. - Wenn Du auf den SELECT vor dem DELETE verzichtest, brauchst Du auch keine Transaktion. - Wenn Du schon UNBEDINGT vor dem DELETE per SELECT abfragen willst, ob was zum Löschen da ist (wie gesagt: ES! IST! NICHT!! NÖTIG!!!), dann verwende `SELECT COUNT(*)` und führe das Command mit ExecuteScalar() aus. Damit bekommst Du die erste Spalte der ersten Ergebniszeile - mehr gibt's bei `SELECT COUNT(*)` auch nicht. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Henry, was tust Du denn da Merkwürdiges?! - Wenn Du das Command mit der CreateCommand-Methode erzeugst, ist die Connection schon drin, die musst Du nicht mehr zuweisen. - Es ist sinnlos, einen SELECT mit ExecuteNonQuery auszuführen. Du möchtest ja Ergebnisdaten bekommen, und die kriegst Du nur mit ExecuteReader oder ExecuteScalar(). Mehr dazu weiter unten. - Beim 2. cmd.ExecuteNonQuery(); stützt das Programm ab - was stützt es denn? 😉 Aber wenn es abstürzt, dann verrate uns bloß nicht, wie. Sonst könnte man ja auf eine Idee kommen, was los ist. Mein Versuch, einen Absturz an dieser Stelle mit einem Spielprogramm nachzuvollziehen (.net Core 8, C# 12, MySqlConnection gegen MariaDB 10.6), gelingt nicht. - Kreative Einrückung macht das Lesen von Code spannend. Ich habe eine Weile gebraucht, um festzustellen, dass dein cmd.ExecuteReader() **außerhalb** des catch steht. - Der ExecuteReader ist sinnlos. Zum einen sehe ich keinen rdr.Read(), und zum anderen ist der CommandText in diesem Moment ein DELETE-Statement, das kein Resultset liefert. Aber er wirft keine Exception, soweit ich das erkennen kann. - Du machst im Fehlerfall einen Rollback, im Erfolgsfall aber keinen Commit! Das musst Du definitiv tun, sonst wird die DB nicht verändert und Du kannst auch keinen weiteren BeginTransaction() aufrufen (weil ja schon eine offen ist). - Dass Du vor dem DELETE keinen SELECT machen musst, haben wir Dir schon gesagt. Der DELETE tut einfach nichts, wenn die WHERE-Bedingung nicht erfüllt ist, und du fängst mit dem SELECT ja auch nichts an, du lässt ihn einfach laufen ohne das Resultset abzuholen. Ich hatte schon gedacht, dass er darüber abstürzt, dass es ein schwebendes Resultset gibt - aber nein, war nicht so, gerade ausprobiert. - Wenn Du schon UNBEDINGT vor dem DELETE per SELECT abfragen willst, ob was zum Löschen da ist (wie gesagt: ES! IST! NICHT!! NÖTIG!!!), dann verwende `SELECT COUNT(*)` und führe das Command mit ExecuteScalar() aus. Damit bekommst Du die erste Spalte der ersten Ergebniszeile - mehr gibt's bei `SELECT COUNT(*)` auch nicht. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Henry, was tust Du denn da Merkwürdiges?! - Wenn Du das Command mit der CreateCommand-Methode erzeugst, ist die Connection schon drin, die musst Du nicht mehr zuweisen. - Beim 2. cmd.ExecuteNonQuery(); stützt das Programm ab - was stützt es denn? 😉 Aber wenn es abstürzt, dann verrate uns bloß nicht, wie. Sonst könnte man ja auf eine Idee kommen, was los ist. Mein Versuch, einen Absturz an dieser Stelle mit einem Spielprogramm nachzuvollziehen (.net Core 8, C# 12, MySqlConnection gegen MariaDB 10.6), gelingt nicht. - Kreative Einrückung macht das Lesen von Code spannend. Ich habe eine Weile gebraucht, um festzustellen, dass dein cmd.ExecuteReader() **außerhalb** des catch steht. - Der ExecuteReader ist sinnlos. Zum einen sehe ich keinen rdr.Read(), und zum anderen ist der CommandText ein DELETE-Statement, das kein Resultset liefert. Aber er wirft keine Exception, soweit ich das erkennen kann. - Du machst im Fehlerfall einen Rollback, im Erfolgsfall aber keinen Commit! Das musst Du definitiv tun, sonst wird die DB nicht verändert und Du kannst auch keinen weiteren BeginTransaction() aufrufen (weil ja schon eine offen ist). - Dass Du vor dem DELETE keinen SELECT machen musst, haben wir Dir schon gesagt. Der DELETE tut einfach nichts, wenn die WHERE-Bedingung nicht erfüllt ist, und du fängst mit dem SELECT ja auch nichts an, du lässt ihn einfach laufen ohne das Resultset abzuholen. Ich hatte schon gedacht, dass er darüber abstürzt, dass es ein schwebendes Resultset gibt - aber nein, war nicht so, gerade ausprobiert. - Wenn Du schon UNBEDINGT vor dem DELETE per SELECT abfragen willst, ob was zum Löschen da ist (wie gesagt: ES! IST! NICHT!! NÖTIG!!!), dann verwende `SELECT COUNT(*)` und führe das Command mit ExecuteScalar() aus. Damit bekommst Du die erste Spalte der ersten Ergebniszeile - mehr gibt's bei `SELECT COUNT(*)` auch nicht. _Rolf_ -- sumpsi - posui - obstruxi