ErControl

Schlägt bei einer mehrstufigen Datenbankmigration (z. B. 2.2.3.53 -> 3.0.0.0 -> aktuelle Version) der zweite Schritt fehl, bleibt die im ersten Schritt angelegte Zwischendatenbank (z. B. ErControl2.sqlite.3.0.0.0.db) im Datenbankordner liegen. Bei jedem weiteren Versuch kommt eine weitere Datei dazu (…3.0.0.0_1.db usw.).

Ursache: In MigrationService.MigrateAsync wird die Zwischendatenbank nur nach erfolgreichem Abschluss von StandardMigrationAsync gelöscht. Zusätzlich konnte das File.Delete im catch-Zweig von StandardMigrationAsync/MigrateFromMinVersionAsync selbst eine IOException auslösen (Datei noch gesperrt, z. B. weil ein per new Prefs(new EcContext(...)) erzeugter Kontext nie disposed wurde) und damit die eigentliche Migrationsfehlermeldung überdecken.

Lösung:

• Schlägt der zweite Schritt fehl, wird die Zwischendatenbank ebenfalls entfernt (die Originaldatenbank bleibt wie bisher unangetastet).
• Neue Hilfsmethode TryDeleteDatabase: gibt gepoolte SQLite-Verbindungen frei, löscht Datenbank und -journal/-wal/-shm-Begleitdateien und protokolliert Fehler beim Löschen nur als Warnung, statt die eigentliche Fehlermeldung zu überdecken.
• Die EcContext-Instanzen für das Setzen der Datenbankversion werden jetzt disposed.

Aufgefallen bei der Analyse fehlgeschlagener Migrationen (fehlende Migration für Training.StageNo, PendingModelChangesWarning).