Schulverwaltungssoftware NRW

Jede neue Migration innerhalb von Schild 3 erfordert einen neuen svws-Server User. Ist das richtig? Eine kurze Erklärung, dass die Angabe in diesem Fenster KEIN DB-User ist sondern ein SVWS-Server User wäre an dieser Stelle hilfreich.

Einen vorhandenen User kann ich (leider) nicht angeben. Dann erhalte ich nämlich diese Fehlermeldung: Wenn viel migriert wird, dann sammeln sich viele verscheidene Nutzer im svws-Server an. Das ist etwas verwirrend (zu Beginn).

Je nach Anwendung verwende ich aber immer den selben Zugang für den svws-User.
Das zu trennen macht eigentlich nur Sinn, wenn es DBs sind, die exklusive Rechte benötigen, also bei DB-Zugriff über DB-Tools.
Dann wird in HeidiSQL, phpmyadmin, DBeaver oder was auch immer das Schema angezeigt, das für den svws-User angelegt wurde. Nur db-root zeigt alle Schemata in der Datenbank.
In Testumgebungen belasse ich es i.d.R. beim default des svwsadmin.
In Schulungsumgebungen wüsste ich noch keine Situation für verschiedenen Userdaten. Das Admin-Tool benötigt eh volle DB-root-Rechte, in Schild/svws sind die normalen Schildzugangsrechte vorgesehen.

Edit: Ich habe evtl. dein Problem falsch verstanden: Beim Miorgration aus Schild3 lässt sich eine weitere DB für den selben svws-User nicht anlegen?
Im Admin-Tool geht das aber, habe es gerade getestet.

Der Benutzer, der dort angelegt wird, wird Admin für das Schema, in das migriert wird. Aber dieser Benutzer wird auf der Ebene des Maria-DB-Servers angelegt, ist also dort einzigartig. Man kann mehrere Schemata mit einem und demselben User verwalten. Dann muss aber bei der Migration das dazugehörige Kennwort eingegeben werden (sich auch Meldungstext oben)

Sofern es keine Gründe gibt, unterschiedliche Schemata zu trennen, würde ich immer den gleichen Schema-Admin verwenden.

Unterschiedliche Schema-Admins machen etwa Sinn, wenn zum Beispiel ein Rechenzentrum eine MariaDB hat, in der auch noch andere Nutzer laufen, etwa die kommunale Führerscheinstelle oder ähnlich. Hier gäbe es ein DB-Root-Kennwort und die unterschiedlichen Kunden werden von unterschiedlichen Schema-Admin-Zugängen verwaltet.

Laufen auf einem Server mehrere Schulen, muss sich der IT-Dienstleister überlegen, ob diese mit unterschiedlichen Schema-Admins verwaltet werden.

In einer Schule, besonders hier in Testumgebungen, würde ich immer den gleichen svws_admin setzen.

1. An den Begriff "Schema" muss ich mich noch sehr gewöhnen! Bis jetzt habe ich als Fachberater mit Datenbanken verschiedener Schulen gearbeitet.

2. Ich muss, wie gesagt aus Schild 3 heraus, über Verwaltung - Datenbank - Datenbank migrieren (aus mdb), immer einen neuen (Schema?-) Benutzer (s.u.) eintragen. Habe ich gerade getestet.
3. Da es zwei Pwd-Felder in dieser Maske (s.o.) gibt, gehe ich als Benutzer davon aus, dass ich einen neuen Benutzer anlege, oder?
Je länger ich mir diese Maske anschaue, desto mehr Fragen tauchen bei mir auf.
Ich war zunächst davon ausgegangen, dass ich eine neue DB migriere und für diese DB einen (Neuen) Benutzer definiere. Wenn ich dann Schild3 starte, stelle ich fest, dass ich mich mit dem eben eingegebenen Benutzer nicht einloggen kann.

viewtopic.php?p=37713#p37713

Evtl. hilfreich? Ja, das ist gewöhnungsbedürftig, liegt aber in der Natur der Sache.

2. Ja, man muss den eintragen, aber man kann einen existierenden nutzen. Oder geht das nicht?

3. Der "Benutzer" ist ein Schema-Benutzer. Das ist hat mit den SchILD-Benutzern nichts zu tun. Eine neue SchILD-Datenbank hat immer den Nutzer "Admin" (ohne Passwort), mit dem man sich dann (Admin-)Nutzer einrichten kann. Den Standart-SchILD-Admin ohne Kennwort gibt es in einer migrierten Datenbank hoffentlich nicht. Migrieren Sie eine SchILD-Datenbank, sind darin die (Admin-)Nutzer ja schon enthalten, mit denen loggen Sie sich dann ein.

Der Schema-Admin wird eigentlich nur gebraucht, um die Connection-File für SchILD3 zu erstellen. Sonst... nie.

Hier finden sich noch Informationen zum Schema und den Nutzern: https://schulverwaltungsinfos.nrw.de/sv ... ?title=FAQ

zu 2) Nein, das muss ein Neuer sein. Sonst kommt die Meldung "..Pruefe, ob der Bunutzer angelegt werden kann. ..." (s.o.)

zu 3) In meinen Test-DBs gibt es jeweils einen "Admin"-User ohne Pwd (zum schnelleren einloggen). Diese DBs kann ich migrieren und logge mich dann anschließend mit Admin / (ohne Pwd) ein.

Zu 2: Das Kennwort muss mit dem des bestehenden Users übereinstimmen. Dann muss es funktionieren andernfalls kommt der Fehler.

Habe alles neu installiert. Jetzt scheint es zu klappen.