DAT-Import scheitert bei Schüler/innen mit mehreren Bildungsgängen
Verfasst: Mittwoch 2. September 2026, 06:02
DAT-Import scheitert bei Schüler/innen mit mehreren Bildungsgängen (bewusste Dubletten) — Lösung in SchILD3/SVWS-Server geplant?
Wir haben uns bei uns am JDBK ein kleines Tool gebaut (Aktuell noch in SchILD2), das bestimmte Änderungen (Adressänderungen, Klassenwechsel, Notenänderungen in alten Abschnitten usw.) automatisiert über die SchILD-DAT-Schnittstelle importiert, statt sie manuell in der Oberfläche einzutragen.
Dabei sind wir auf folgendes Problem gestoßen: Bei uns durchlaufen viele Schüler/innen im Laufe der Zeit mehrere Bildungsgänge (z. B. erst eine schulische AV Maßnahme, dann BFS und noch eine duale Ausbildung). Für jeden neuen Bildungsgang legen wir bewusst einen neuen Schüler-Datensatz an, statt den bestehenden weiterzuführen — das ist bei uns Absicht: Würden wir stattdessen den alten Datensatz einfach weiterlaufen lassen, hätten wir bei Zeugnisnachdrucken usw. das Problem, dass Beginn und Ende des jeweiligen Bildungsgangs in SchILD nicht sauber ausgewiesen sind — dieses Feld zieht ja den Eintritts- und Endtermin des allerersten Bildungsgangs mit. Für eine korrekte Schülerlaufbahn pro Bildungsgang brauchen wir also getrennte Datensätze.
Das führt aber zu folgendem Nebeneffekt: Derselbe Mensch (identischer Vorname, Nachname, Geburtsdatum) existiert dadurch mehrfach in der Datenbank (als Duplikat) — der/die „alte" Datensätze bleibt als Abgänger/Abschluss stehen, daneben der neue, aktive.
Die DAT-Importschnittstelle identifiziert Schüler/innen offenbar ausschließlich über Nachname+Vorname+Geburtsdatum. Trifft dieser Schlüssel auf mehr als einen Datensatz zu, lehnt SchILD den Import mit einer Meldung in Richtung „gefunden, aber nicht eindeutig identifizierbar" ab — auch wenn der aktive Datensatz für einen menschlichen Bearbeiter eindeutig erkennbar wäre.
Workaround bei uns: Wir gleichen vor jedem Import zusätzlich gegen eine separate, vollständige Ehemaligen-Liste ab und schließen betroffene Fälle vom Automatik-Import aus (manuelle Nachbearbeitung in der Oberfläche). Funktioniert, ist aber Zusatzaufwand und nur so gut wie die Aktualität dieser Liste.
Fragen:
Gibt es in SchILD einen anderen Weg/Modus, pro Bildungsgang ein sauberes Beginn-/Enddatum zu führen, OHNE dafür einen komplett neuen Personendatensatz anzulegen? Dann könnten wir uns die Dubletten evtl. sparen.
Falls nicht: Kennt jemand einen saubereren Umgang mit dem DAT-Import in genau diesem Fall (Name+Geburtsdatum nicht eindeutig)?
Ist bekannt, ob SchILD3 bzw. der SVWS-Server für den Import eine stabilere, eindeutige Schüler-ID statt Name+Geburtsdatum als Matching-Schlüssel verwenden wird oder zumindest auf den Status "aktiv"? Das würde das Import-Problem lösen, auch wenn man weiterhin pro Bildungsgang getrennte Datensätze anlegt.
Grüße
Wir haben uns bei uns am JDBK ein kleines Tool gebaut (Aktuell noch in SchILD2), das bestimmte Änderungen (Adressänderungen, Klassenwechsel, Notenänderungen in alten Abschnitten usw.) automatisiert über die SchILD-DAT-Schnittstelle importiert, statt sie manuell in der Oberfläche einzutragen.
Dabei sind wir auf folgendes Problem gestoßen: Bei uns durchlaufen viele Schüler/innen im Laufe der Zeit mehrere Bildungsgänge (z. B. erst eine schulische AV Maßnahme, dann BFS und noch eine duale Ausbildung). Für jeden neuen Bildungsgang legen wir bewusst einen neuen Schüler-Datensatz an, statt den bestehenden weiterzuführen — das ist bei uns Absicht: Würden wir stattdessen den alten Datensatz einfach weiterlaufen lassen, hätten wir bei Zeugnisnachdrucken usw. das Problem, dass Beginn und Ende des jeweiligen Bildungsgangs in SchILD nicht sauber ausgewiesen sind — dieses Feld zieht ja den Eintritts- und Endtermin des allerersten Bildungsgangs mit. Für eine korrekte Schülerlaufbahn pro Bildungsgang brauchen wir also getrennte Datensätze.
Das führt aber zu folgendem Nebeneffekt: Derselbe Mensch (identischer Vorname, Nachname, Geburtsdatum) existiert dadurch mehrfach in der Datenbank (als Duplikat) — der/die „alte" Datensätze bleibt als Abgänger/Abschluss stehen, daneben der neue, aktive.
Die DAT-Importschnittstelle identifiziert Schüler/innen offenbar ausschließlich über Nachname+Vorname+Geburtsdatum. Trifft dieser Schlüssel auf mehr als einen Datensatz zu, lehnt SchILD den Import mit einer Meldung in Richtung „gefunden, aber nicht eindeutig identifizierbar" ab — auch wenn der aktive Datensatz für einen menschlichen Bearbeiter eindeutig erkennbar wäre.
Workaround bei uns: Wir gleichen vor jedem Import zusätzlich gegen eine separate, vollständige Ehemaligen-Liste ab und schließen betroffene Fälle vom Automatik-Import aus (manuelle Nachbearbeitung in der Oberfläche). Funktioniert, ist aber Zusatzaufwand und nur so gut wie die Aktualität dieser Liste.
Fragen:
Gibt es in SchILD einen anderen Weg/Modus, pro Bildungsgang ein sauberes Beginn-/Enddatum zu führen, OHNE dafür einen komplett neuen Personendatensatz anzulegen? Dann könnten wir uns die Dubletten evtl. sparen.
Falls nicht: Kennt jemand einen saubereren Umgang mit dem DAT-Import in genau diesem Fall (Name+Geburtsdatum nicht eindeutig)?
Ist bekannt, ob SchILD3 bzw. der SVWS-Server für den Import eine stabilere, eindeutige Schüler-ID statt Name+Geburtsdatum als Matching-Schlüssel verwenden wird oder zumindest auf den Status "aktiv"? Das würde das Import-Problem lösen, auch wenn man weiterhin pro Bildungsgang getrennte Datensätze anlegt.
Grüße