ASDPC im Parallelbetrieb Schild2 und 3

[Frodermann]

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.

[Frodermann]

• 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?

[Frodermann]

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.

[Frodermann]

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?

[Raffenberg]

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.