DATA
Daten
Sind Lehrkräfte-, Fach-, Klassen-, Wochenstunden- und Zeitdaten korrekt?
Hilfe-Center · Fehlerbehebung
Bestimmen Sie zuerst, zu welcher Ebene das Problem gehört, bevor Sie etwas ändern.
Dasselbe Symptom kann in Dersiva unterschiedliche Ursachen haben. Eine nicht platzierte Stunde kann ein Kapazitätsproblem sein, während ein plötzliches Beenden auf Laufzeit- oder native Solver-Komponenten hinweisen kann. Diagnose ist schneller als zufällige Änderungen.
Vier Diagnoseebenen
Ordnen Sie das Problem zuerst der richtigen Klasse zu.
RULES
Bedingungen
Blockieren Sperrtage, Tagesgrenzen, Blöcke oder gemeinsame Stunden den Lösungsraum?
RUNTIME
Laufzeit
Sind Anwendung, .NET, native OR-Tools-Komponenten und Visual-C++-Runtime intakt?
PUBLISH
Veröffentlichung / Verbindung
Verwenden API, Lizenzprüfung, Lehrkräfteportal oder Ausgaben die richtige Quelle?
Schnelle Symptomzuordnung
Das sichtbare Symptom bestimmt den ersten Prüfpunkt.
Anwendung startet nicht
Installation / Laufzeit
→Anwendung schließt bei der Planung
Laufzeit / nativer Solver
→Einige Stunden werden nicht platziert
Daten / Kapazität / harte Bedingungen
→Lizenzprüfung schlägt fehl
Netzwerk / DNS / API
→Portal wird nicht aktualisiert
Gültiger Plan / API / Portal
→PDF/Ausgabe wirkt veraltet
Plan-Snapshot / Ausgabequelle
→Sicherung lässt sich nicht wiederherstellen
Datei / Version / Umfang
→01
Symptom zusammen mit der Prozessphase definieren
Statt „funktioniert nicht“ wird die genaue Phase bestimmt: Programmstart, Dateneingabe, Solver-Start, Solver-Lauf, Planabschluss, Veröffentlichung, Ausgabe oder Wiederherstellung. Dieselbe Fehlermeldung kann in verschiedenen Phasen etwas anderes bedeuten.
02
Version, Uhrzeit und Ausführungsmodus notieren
Notieren Sie Dersiva-Version, ungefähre Uhrzeit, Erstellungsmodus, Status des sicheren Diagnosemodus und sichtbaren Fehlertext. Zeitangaben erleichtern die Zuordnung zu Logs und Windows-Ereignissen.
03
Vor größeren Änderungen sichern
Erstellen Sie eine aktuelle `.ddbackup`, bevor Bedingungen massenhaft entfernt, Daten zurückgesetzt, das Programm neu installiert oder eine andere Sicherung wiederhergestellt wird. Fehlerbehebung darf nicht zum Datenverlust führen.
04
Zuerst das grundlegende Datenmodell prüfen
Geplante Wochenlasten der Lehrkräfte, Klassenstunden, Unterrichtszuweisungen und Schulzeitraster müssen zusammenpassen. Falsche Wochenstunden oder fehlende Zuweisungen verursachen unabhängig vom Solver Probleme.
05
Nicht platzierte Stunden schichtweise diagnostizieren
Prüfen Sie Lehrkraftverfügbarkeit, Tagesmaximum, offene Klassenzeiten, gemeinsame Stunden und andere harte Bedingungen zusammen. Eine nicht platzierte Stunde ist kein Programmabsturz und benötigt normalerweise eine Machbarkeits- und Kapazitätsanalyse.
06
Konflikte harter Bedingungen trennen
Sperrtage, exakte Tageshöchstwerte, Pflichtblöcke, gemeinsame Stunden oder geschützte Tage können einzeln korrekt sein, aber gemeinsam das Modell unlösbar machen. Präferenzen sollten nicht unnötig als harte Bedingungen definiert werden.
07
Schlechte Qualität nicht mit technischem Fehler verwechseln
Ein Plan kann vollständig sein und trotzdem schlechte Freistunden oder Tagesdichte besitzen. Das ist ein Qualitätsproblem. Nicht platzierte Stunden oder ein Prozessabsturz benötigen einen anderen Diagnoseweg.
08
Bei plötzlichem Ende während der Planung die Laufzeitebene prüfen
Schließt der Prozess ohne normale Fehlermeldung oder zeigt Windows eine `Google.OrTools.Sat.SolveWrapper.Solve`-/Native-Aufrufkette, sollten Laufzeit und native Solver-Abhängigkeiten vor Änderungen an den Plandaten geprüft werden. Dies ist nicht dasselbe wie ein mathematisches „keine Lösung“.
09
Mit Sicherem Diagnosemodus — 1 Worker vergleichen
Wenn der normale Multi-Worker-Lauf endet, dieselben Daten aber mit 1 Worker laufen, ist das ein wichtiges Diagnosesignal. Es beweist die Ursache nicht, weist aber auf Worker-/Native-Verhalten, Prozessorumgebung und Abhängigkeiten hin.
10
OR-Tools native und Visual-C++-Runtime prüfen
Der Solver verwendet neben .NET auch native OR-Tools-Komponenten. Fehlende, beschädigte oder inkompatible Komponenten wie Microsoft Visual C++ 2015–2022 Redistributable x64 können native Aufrufe beeinträchtigen. Aktuelle Installationsvoraussetzungen müssen geprüft werden.
11
Umgebungen vergleichen, wenn dieselbe Sicherung unterschiedlich reagiert
Funktionieren dieselbe Dersiva-Version und `.ddbackup` auf einem Computer, aber nicht auf einem anderen, sollten die Daten nicht sofort verändert werden. Vergleichen Sie Windows-Version, Visual-C++-Runtime, Prozessor/Worker-Verhalten, Sicherheitssoftware und Installationsintegrität.
12
`log.txt` und globale Fehleraufzeichnung nach Zeitstempel lesen
Suchen Sie in Dersiva-Diagnosen nach Fehlerzeit, Operation und Managed-Exception. Endet der Prozess bereits im nativen Code, kann `log.txt` unvollständig bleiben; dann sind Windows-Ereignisse wichtiger.
13
Windows-Anwendungsereignis prüfen
Bei abruptem Ende prüfen Sie im Windows Application Log fehlerhaftes Modul sowie .NET/CoreCLR-Stack. `SolveWrapper_Solve` zeigt, dass der Fehler während des OR-Tools-Aufrufs auftrat, bestimmt aber allein nicht die Grundursache.
14
Lizenz- oder API-Fehler Ende-zu-Ende trennen
Funktionierendes Internet beweist keine API-Erreichbarkeit. Prüfen Sie DNS, HTTPS, Schulnetzfilter/Sicherheit, relevante Dersiva-Domain und API-Antwort separat. Browserzugriff und Anwendungszugriff sind nicht derselbe Test.
15
Portalveröffentlichung über vier Prüfpunkte verfolgen
Prüfen Sie zuerst, ob der richtige Plan gültig ist. Danach folgen Desktop-Veröffentlichungs-Snapshot, an die API gesendete Daten, serverseitige Quellenrevision und Portaldarstellung. Ein Testplan darf die offizielle Portalquelle nicht ersetzen.
16
Bei veralteter Ausgabe die Snapshot-Quelle prüfen
Zeigt PDF oder Ausgabe einen unerwarteten Plan, muss ermittelt werden, aus welchem Snapshot sie erzeugt wurde. Letzter Plan, Testplan und gültiger Plan sind unterschiedliche Zustände.
17
Bei Wiederherstellungsproblemen Datei, Umfang und Version trennen
Prüfen Sie Zugriff auf `.ddbackup`, gewählten Wiederherstellungsumfang und Zielversion. Für den Computerumzug wird der unterstützte Wiederherstellungsweg verwendet, nicht das direkte Kopieren des alten Programmordners oder maschinenspezifischer Schlüssel.
18
Bei Eskalation ein sicheres Diagnosepaket vorbereiten
Sammeln Sie Dersiva-Version, Problemzeit, Prozessphase, Modus, sichtbaren Fehlertext, relevanten `log.txt`-Abschnitt und bei Bedarf Windows-Ereignisinformationen. Passwörter, Lizenzgeheimnisse und unnötige personenbezogene Daten gehören nicht hinein.
Kontrolle in den ersten fünf Minuten
Vor Änderungen diese Reihenfolge verwenden.
Klassifizieren
Daten, Bedingungen, Laufzeit oder Veröffentlichung?
Zustand notieren
Version + Zeit + Modus + Fehlertext.
Sicherung erstellen
Vor Änderungen einen Rückkehrpunkt schaffen.
Kleinsten Test ausführen
Je nach Problem 1 Worker, ein Beispielkonto oder eine Ausgabe verwenden.
Nach Belegen handeln
Nur die durch Logs und Vergleich bestätigte Ebene korrigieren.
Teuerster Fehler bei der Diagnose
Viele Variablen gleichzeitig ändern, bevor Belege gesammelt wurden.
Bedingungen entfernen, Anwendung neu installieren, Sicherungen wiederherstellen und Netzwerkeinstellungen gleichzeitig ändern macht die Ursache unsichtbar. Ändern Sie jeweils nur eine Variable und dokumentieren Sie das Ergebnis.
Hilfe-Center