Schulverwaltungssoftware NRW

Hallo zusammen,

habe ich das eben in https://schulverwaltungsinfos.nrw.de/sv ... stallation richtig gelesen, dass man auf einem PC besser nicht Schild2 und Schild3 zur Verfügung stellt, weil beim Registrieren der Statistik-DLLs nur die jeweils zuletzt installierten/registrierten DLLs gezogen werden ?

Das könnte aber in einem Umfeld mit zentraler Bereitstellung problematisch werden, wenn sich Schulen für einen Paralleltest von Schild3 melden. Dann müssten wir das auf die PCs reduzieren, die klassischerweise nicht mit ASDPC arbeiten.

Besteht denn da nicht die Möglichkeit die DLLs für Schild3 anders zu benennen ? Oder wie sieht das Konzept für einen Paralleltestbetrieb von Schild2 und 3 aus ?

Schöne Grüße
Thomas Hagel

Stadt Köln
Fachanwendungsbetreuung

Da geht es nur um die Registrierung der Statistik-dlls, das Verhalten ist identisch zu heute, wenn man mehrere SchILD2-Installationen einsetzen möchte (wieso auch immer), was auch nicht empfohlen wird.

Wurde auf einem Rechner, der SchILD3 ausführt, die Registrierung nicht ausgeführt, läuft die Statistikprüfung halt nicht - so wie heute in SchILD2 auch. ASDPC wird ja üblicherweise auch nur auf sehr wenigen Rechnern verwendet. Auf allen SchILD3-Rechnern kann man getrost die dlls registrieren, die greifen ohnehin alle auf die gleiche Netzwerkinstallation zu.

Im typischen Fall führt man aber doch ohnehin Netzwerkinstallationen aus, die auf ein auf dem Server liegendes SchILD (2 oder 3) zugreifen, anstatt auf Einzelclients mit eigenen Installationen zu rekurrieren. Gibt es überhaupt einen Fall, in dem jemand SchILD2 und SchILD 3 parallel für die Statistik verwenden möchte? In SchILD werden die Daten nur aufbereitet, geprüft, verbessert, geprüft - dann geht es per Textdateien in ASDPC.

Es gibt kein Konzept für den Parallelbetrieb von SchILD2 und 3. Wer das am Anfang tun möchte und technisch sauber aufsetzt und drauf achtet, dass SchILD2 und 3 aktuell sind und auf die jeweils aktuellen dlls mit ihren jeweiligen Windows-Klienten zugreifen können, kann das tun. Ob die Features von SchILD3 und dem SVWS-Server auf der einen und SchILD2 auf der anderen Seite irgendwann zu weit auseinanderlaufen, mag sein, ist derzeit aber nicht so.

Genau wegen der Frage "Auf welchem Rechner ist welches SchILD in welcher Installationsversion, eventuell mehrfach oder lokal und und greift auf welche Netzfreigabe, über welche dll-Registrierung zu und was sind vielleicht noch Altlasten, von Klienten oder Registrierungen und wer hat wo welche Übersicht oder auch nicht und wie lange sind SchILD 2 und 3 noch kompatibel?" steht da "Stellen Sie einmal sauber auf SchILD3 um". Im kompetenten Einzelfall kann man beides durchaus für den einen oder anderen Anwendungsfall unter einen Hut bekommen.

Was ist denn die Problemstellung? Die Schule läuft auf SchILD2, und ein paar Rechner probieren SchILD3 aus? SchILD3 und SchILD2 brauchen für die Statistik ohnehin die gleichen dlls, da kann sich der Rechner von SchILD2 ruhig die aus SchILD3 holen, sofern alles für die Statistik gewissenhaft auf den immer aktuellen Stand gebracht wird.

Wir haben es in Köln aber nicht mit dem "typischen Fall" zu tun ... Eher im Gegenteil. Die Problemstellung ergibt sich bei uns aus rund 260 städtischen Schulen an rund 290 Standorten, in denen rund 2.500 Anwender an rund 2.000 PCs mit SchildZentral arbeiten. Plus die rund 2.300 TerminalUser-Benutzer, die SchildZentral auch von außerhalb des Schulgebäudes nutzen können.

Für eine einzelne Schule mit ein paar PCs ist das Problem mit derzeit Schild2 oder Schild3 und ASDPC eher klein... es ist aber etwas, was offenbar bei dem Vorhaben Schild2 und 3 parallel laufen zu lassen, bedacht werden muss. Gegen eine Netzinstallation sprechen der rund 560 MB-große Programmordner von SchildZentral und mit all seinen Modulen.

In unserem Fall geht es also darum, den Schild3-Client neben der lokalen Schild2-Installation bereitstellen zu können. Das wird in den meisten Fällen unproblematisch sein. Aber da wo z.B. die Schulen auch gegen ASDPC und Schild3 testen wollen, müssten wir dann irgendwie improvisieren. Z.B. damit, dass auf den PCs Schild3 installiert wird und die an den Tests teilnehmenden Schulen dann ASDPC und Schild2 nur unter TerminalServer nutzen können.

Was aber spricht dagegen, die DLLs für Schild3/ASDPC entsprechend umzubenennen, so dass das Problem gar nicht erst auftreten kann ?

• Wird SchILD zentral überhaupt "SchILD2" und "SchILD3" haben? Oder kommt der Tag, an dem das "Produkt SchILD zentral" die Versionsnummer erhöht und alles läuft nur noch auf der neuen Version? Hier würde ich direkt bei Ribeka nachfragen, denn eigentlich widerspricht die Option, zwei Versionen zu betreiben grundsätzlich der Idee des zentralen Systems.
• Kann SchILD2 überhaupt auf SchILD3-Datenbanken zugreifen? SchILD3-Datenbanken laufen alle auf einer MariaDB - zusammen mit der Führerscheinstelle und was auch immer andere Kunden auf der MariaDB haben - dann aber in einem eigenen Schema für jede Schule. Wird SchILD2 diese "Schemas" auch unterstützen? Gleichfalls greift SchILD3 so wie ich das verstanden habe auch nicht direkt auf SchILD2-Datenbanken zu. Hierzu müsste eventuell Ribeka ebenfalls mitteilen, ob das überhaupt so angedacht und technisch möglich ist.

Wissen Sie hier mehr?

Ich verstehe das mit dem "Testen" jetzt so, dass SchILD3 im Produktiveinsatz auf den echten Daten neben der alten SchILD2-Installation - SchILD-NRW2 oder SchILD zentral (das noch SchILD2 ist) - laufen soll, um zu evaluieren, ob man umsteigen möchte oder nicht?

Oder soll SchILD3 neben SchILD2 (oder SchILD-NRW2) mit Test-Daten laufen, wobei die alte Variante die des Produktiveinsatzes ist und die neue der Umstiegsevaluation dienen soll?

Hierbei kommen mir die DLLs als das kleineste Problem vor. Egal ob SchILD2, 3 oder zentral: Für die Statistik macht es nur Sinn, wenn alle SchILDe und ASDPC mit all ihren DLLs auf dem gleichen Stand sind. Ganz gleich, wo was liegt oder ob S2-> ASDPC oder S3->ASDPC angedacht ist, es muss immer alles aktuell sein und da die dlls identisch sind, spielt es keine Rolle, welche der registrierten ddls nun abgegriffen werden.

Mir leuchtet vollkommen ein, dass man SchILD3 testen möchte. Aber der Statistikablauf in SchILD als Vorbereitung zu ASDPC ist identisch. Hier müsste man sich nur überlegen, ob man einen SchILD3-Klienten auf einem Produktivrechner ausprobieren möchte, der auch die Statistik mit dem noch laufenden System macht.

Mein Problem hier gerade: Ich verstehe, was gemacht werden soll. Aber ich verstehe nicht, wieso man SchILD2 und 3 parallel in Bezug auf die Statistikdateien laufen lassen sollte. Was soll das Ergebnis sein? SchILD3 erzeugt im Vergleich zu SchILD2 mit den gleichen ddls aus den gleichen Daten und dem gleichen technischen Vorgang die gleichen Exportdateien für ASDPC.

Lange Rede, kurzer Sinn:

In unserem Fall geht es also darum, den Schild3-Client neben der lokalen Schild2-Installation bereitstellen zu können. Das wird in den meisten Fällen unproblematisch sein.

Das sehe ich auch so. Zur Statistik: viel zu Testen gibt es dort nicht. Hilft das?

• Wird SchILD zentral überhaupt "SchILD2" und "SchILD3" haben? Oder kommt der Tag, an dem das "Produkt SchILD zentral" die Versionsnummer erhöht und alles läuft nur noch auf der neuen Version? Hier würde ich direkt bei Ribeka nachfragen, denn eigentlich widerspricht die Option, zwei Versionen zu betreiben grundsätzlich der Idee des zentralen Systems.

Nun, wir sind seit Anfang des letzten Jahres im Austausch mit IT.NRW/MSB, sowie Ribeka. Eigentlich wollten wir erst auf den "Zug" aufspringen, wenn bereits andere Kommunen ihre Erfahrungen gemacht haben, haben uns aber anders entschieden und sind seit Anfang diesen Jahres dabei SchildZentral3 zum Laufen zu bringen.

SchildZentral3 und seine Module wird wie bereits SchildZentral2 immer auf den Versionen von IT.NRW/MSB basieren, jedoch um Komponenten erweitert, die auf eine zentrale Bereitstellung und Nutzung im Rechenzentrumsverbund abzielt. Dazu gibt es noch vielfältige Werkzeuge für Schulträger.

Ich bin mit meinen Kollegen und Kolleginnen vom Amt für Informationstechnik für die technische Bereitstellung und Fehleranalyse für die SchILD-Anwendungen (und andere schulische Fachanwendungen) zuständig ... und habe das große Vergnügen auch die Projektleitung für die Einführung von SchildZentral3 zu haben. D.h. wir sind da recht intensiv mit Ribeka und IT.NRW/MSB im Austausch.

Kann SchILD2 überhaupt auf SchILD3-Datenbanken zugreifen? SchILD3-Datenbanken laufen alle auf einer MariaDB - zusammen mit der Führerscheinstelle und was auch immer andere Kunden auf der MariaDB haben - dann aber in einem eigenen Schema für jede Schule. Wird SchILD2 diese "Schemas" auch unterstützen? Gleichfalls greift SchILD3 so wie ich das verstanden habe auch nicht direkt auf SchILD2-Datenbanken zu. Hierzu müsste eventuell Ribeka ebenfalls mitteilen, ob das überhaupt so angedacht und technisch möglich ist.

Schild2 kann nicht auf Schild3-Datenbanken zugreifen. Technisch ließe sich das freilich lösen, macht aber keinen Sinn. Schild2 wird diese Schild3-Schemas nicht nutzen. Warum auch ? Die Schild3-Datenbank wurde komplett von Grund auf neu aufgebaut und so von allen gewachsenen historischen Datenbank-Sünden befreit. Hinzu kommt, dass unter SchildZentral3 für alle Module und Daten, die nicht im sog. SchildNRW-Schema erfasst werden, in eigenen Datenbanken/-Schemas abgelegt werden müssen. So also wird es in Köln also neben der Schild3-Datenbank (SchildNRW-Schema) auch je eine Datenbank für SchildWeb, SchildMedia und das digitale Klassenbuchmodul geben ... Angesichts dieser Mengen wird es dann wahrscheinlich einen oder zwei Datenbankserver geben, auf denen ausschließlich Schild-Datenbanken liegen werden.

Ich verstehe das mit dem "Testen" jetzt so, dass SchILD3 im Produktiveinsatz auf den echten Daten neben der alten SchILD2-Installation - SchILD-NRW2 oder SchILD zentral (das noch SchILD2 ist) - laufen soll, um zu evaluieren, ob man umsteigen möchte oder nicht?

Es ist weniger eine Frage ob man möchte oder nicht, sondern, SchildZentral3 wird kommen. Die Frage ist nur, wann ?
Damit die Tests unter SchildZentral3 laufen können, liefert der SVWS-Server ein Datenbankmigrationstool mit. D.h. dass der SVWS-Server sich mit der SchildZentral2-Datenbank verbindet und die Daten je Schulnummer ausliest und in die Schild3-Datenbank exportiert. Ribeka stellt darüber hinaus mit dem sog. Schemaverwaltungsprogramm ebenfalls eine Möglichkeit bereit, die Daten von der alten SchildZentral2-Datenbank schulweise auf die SchildZentral3-Datenbanken zu migrieren.

Mein Problem hier gerade: Ich verstehe, was gemacht werden soll. Aber ich verstehe nicht, wieso man SchILD2 und 3 parallel in Bezug auf die Statistikdateien laufen lassen sollte. Was soll das Ergebnis sein? SchILD3 erzeugt im Vergleich zu SchILD2 mit den gleichen ddls aus den gleichen Daten und dem gleichen technischen Vorgang die gleichen Exportdateien für ASDPC.

Mir würde hierzu einfallen, um festzustellen, ob ASDPC z.B. in beiden Fällen die gleichen Ergebnisse (oder Fehlerberichte) auswirft oder evtl. sogar besser funktioniert. Bzw. mein Problem ist, dass wenn ich hier einen PC habe, an dem z.B. jemand für die Schulstatistik zuständig ist, aber eben auch Schild3 testen möchte. ASDPC und SchildZentral2 sind ja hier quasi vorinstalliert. Und dann kommt SchildZentral3 dazu und würde die DLLs ebenfalls registrieren, die dann aber offenbar SchildZentral3 zugewiesen werden. Demnach würde dann ASDPC im Verbund mit SchildZentral2 nicht mehr funktionieren ... es wäre ein "Entweder SchildZentral2 und ASDPC" oder "ASDPC und SchildZentral3" ...

Und dann kommt SchildZentral3 dazu und würde die DLLs ebenfalls registrieren, die dann aber offenbar SchildZentral3 zugewiesen werden. Demnach würde dann ASDPC im Verbund mit SchildZentral2 nicht mehr funktionieren ... es wäre ein "Entweder SchildZentral2 und ASDPC" oder "ASDPC und SchildZentral3" ...

Genau hier frage ich mich, ob das überhaupt ein Problem ist.
1. Die dlls von SchILD 2und SchILD3 sind technisch (bislang) die gleichen.
2. Die DLL-Registratur ist eine Windowsfunktion, d.h. sie sind im Betriebssystem registriert und nicht "SchIlD2 zugeordnet" oder "SchILD3 zugeordnet".
3. Für die Statistik müssen die immer aktuellen dlls verwendet werden.

Ob der aktuelle Windows-Client sich die aus SchILD2 oder SchILD3 holt, ist damit ja unerheblich. Installiert man erst SchILD2, dann SchILD3, wären die DDLs in Windows im SchILD3-Pfad registriert. Egal ob man die Statistikprüfung von SchILD2 oder SchILD3 anstößt, holen sich beide die aus SchILD3.

Was nun nicht passieren darf wäre, dass man die Dateien von SchILD2 registriert hat, dann SchILD3 nutzt und SchILD2 veralten lässt und die Statistikprüfung aus SchILD3 holt sich weiterhin die alten ddls aus SchILD2 und ignoriert die immer aktuellen aus der eigenen Installation.

Jetzt meine Frage: Habe ich hier etwas mit SchILD zentral nicht verstanden und ein lokales SchILD3 hat keinen direkten Zugriff auf den Speicherort der DLLS von SchILD2 zentral (oder andersherum, SchILD 2 zentral käme nicht an lokal liegenden und auf dem Rechner registrierten dlls von SchILD 3).

Zum Testen wäre hier ein Lösungsvorschlag:
SchILD selbst hat die Funktion, die dlls auf dem lokalen Rechner zu registrieren. Möchte man also SchILD3 testen, würde man die Registrierung von SchILD3 aus durchführen; möchte man dann mit SchILD2 die echte Statistik fahren oder SIM.txt usw. zum Vergleich erzeugen, würde man vorher die Registrierung anstoßen. Geht das auch mit SchILD zentral?

Hierzu bräuchte man natürlich Windows-Admin-Rechte auf dem betreffenden Rechner. Das wird vermutlich nicht immer gegeben sein.

Und es besteht auch die Möglichkeit mit Terminalserver/Remotedesktop. Hier könnte man SchILD3 auf einem Rechner aufsetzen und wer das dann vom Hauptrechner, der noch immer mit dem Produktiv-SchILD2-zentral läuft, per Remote Desktop auf den Rechner mit SchILD3 gehen und kann dort testen und Dateien erzeugen.

[...]Was nun nicht passieren darf wäre, dass man die Dateien von SchILD2 registriert hat, dann SchILD3 nutzt und SchILD2 veralten lässt und die Statistikprüfung aus SchILD3 holt sich weiterhin die alten ddls aus SchILD2 und ignoriert die immer aktuellen aus der eigenen Installation.

Vielleicht besteht hier auch schon ein Missverständnis über die Art und Weise, wie Programme auf den PCs und unter Terminalserver bei uns bereitgestellt werden. Für die Programmverteilung nutzen wir Installationspakete und verteilen diese zentral. Ein Teil dieser Pakete enthält dann u.a. die Registrierung der DLLs und OCX-Dateien, sowie eine Routine zur Deregistrierung, wenn das Programm deinstalliert wird (z.B. bei Updates). Ein Blick in die Registry eines PCs auf dem zuerst SchildZentral2 installiert wurde und dann der SchildZentral3-Client, zeigt, dass z.B. die Datei ASDStatistik.dll hier immer im Kontext der Installation von SchildZentral3 vorliegt.

Starte ich auf dem PC SchildZentral2, kann ich hier zwar die Gesamtprüfung starten und Exporte veranlassen, komme dann aber nicht weiter, weil wir keine Testschule haben, die "in der Schuldatei gefunden" werden kann. Ich weiß leider nicht, ob hier schon diese DLL zum Einsatz kommt, oder erst an einem anderen Zeitpunkt.

Bzw. was bewirken diese DLLs / OCX-Dateien überhaupt ?

[quote}
Jetzt meine Frage: Habe ich hier etwas mit SchILD zentral nicht verstanden und ein lokales SchILD3 hat keinen direkten Zugriff auf den Speicherort der DLLS von SchILD2 zentral (oder andersherum, SchILD 2 zentral käme nicht an lokal liegenden und auf dem Rechner registrierten dlls von SchILD 3).
[/quote]

Technisch könnte ein Zugriff erfolgen, aber wo würde das eingestellt werden ? Vielleicht wäre es einfacher, wenn diese Statistik-DLLs in einen eigenen Ordner ausgelagert würden, um zumindest einen vorübergehenden Parallelbetrieb zu ermöglichen. D.h. es müsste dann in SchildZentral oder in dieser Admin.ini-Datei ein Pfad hinterlegt werden, wo diese zu registrierenden Dateien zu finden sind.

[/qoute]Zum Testen wäre hier ein Lösungsvorschlag:
SchILD selbst hat die Funktion, die dlls auf dem lokalen Rechner zu registrieren. Möchte man also SchILD3 testen, würde man die Registrierung von SchILD3 aus durchführen; möchte man dann mit SchILD2 die echte Statistik fahren oder SIM.txt usw. zum Vergleich erzeugen, würde man vorher die Registrierung anstoßen. Geht das auch mit SchILD zentral?[/quote]
Ich hoffe, dass SchildZentral das nicht kann. Zumal unsere Schild-Anwender nicht die notwendigen Rechte haben und bekommen.

Und es besteht auch die Möglichkeit mit Terminalserver/Remotedesktop. Hier könnte man SchILD3 auf einem Rechner aufsetzen und wer das dann vom Hauptrechner, der noch immer mit dem Produktiv-SchILD2-zentral läuft, per Remote Desktop auf den Rechner mit SchILD3 gehen und kann dort testen und Dateien erzeugen.

Ist bei uns wegen der Menge an bereitzustellenden (virtuellen Test-PCs) ein bisschen komplizierter ... Es wäre dann auch zu testen, wie sich das Konstrukt unter Terminal-Server verhalten wird, wenn wir auch da Schild2 und 3 testen wollen ...

Da verstehe ich das Problem mit dem Terminalserver. Gibt es hier Probleme, so lange die ddls die identischen sind?

Starte ich auf dem PC SchildZentral2, kann ich hier zwar die Gesamtprüfung starten und Exporte veranlassen, komme dann aber nicht weiter, weil wir keine Testschule haben, die "in der Schuldatei gefunden" werden kann. Ich weiß leider nicht, ob hier schon diese DLL zum Einsatz kommt, oder erst an einem anderen Zeitpunkt.

Das Anonymisierungstool, mit dem Testdatenbanken erzeugt werden, setzt eine Fantasieschule mit fiktiver Schulnummer. Können Sie intern mit einer migrierten Realdatenbank arbeiten oder ist das aus Datenschutzrechtlichen Gründen nicht möglich? Wird der Fehler auch bei realen Datenbanken erzeugt?

Da verstehe ich das Problem mit dem Terminalserver. Gibt es hier Probleme, so lange die ddls die identischen sind?

Das wird sich dann wohl zeigen ... soweit sind wir noch nicht, dass wir einen funktionsföhigen Schild3-Client für SchildZentral vorliegen haben ...

Das Anonymisierungstool, mit dem Testdatenbanken erzeugt werden, setzt eine Fantasieschule mit fiktiver Schulnummer. Können Sie intern mit einer migrierten Realdatenbank arbeiten oder ist das aus Datenschutzrechtlichen Gründen nicht möglich? Wird der Fehler auch bei realen Datenbanken erzeugt?

Ich glaube, das könnte erst klappen, wenn in der Schulver.mdb dann auch diese fiktive Schulnummer mit den Eckdaten erfasst ist. Sobald wir funktionierende Schild3-Clients haben, werde das mal mit einer realen Schulen auf einem virtuellen Test-PC mit der Entwicklungs-Datenbank testen und berichten ...

Im zweiten Schritt wäre das auf der Entwicklungsumgebung unter TerminalServer zu testen sein ...

Hallo Herr Hagel,
SchILDzentral-Kunden müssen sich hier bei den prognostizierten Problemen mit der Firma ribeka abstimmen. Herr Richter liest im Forum nicht mit. SchILD-NRW Kunden haben viele der Probleme nicht, die SchILDzentral Kunden haben.