Wir verwenden seid geraumer Zeit die Lokale Datenbank auf einem Windows Server zur 24/7 ausspielung. Als Datei *.mldb
Nun gehen wir mehr und mehr dazu über die Moderatoren auch mit dieser Datenbank zu verbinden über die dbserver.bat
Bedeutet das diese Tagsüber sich die Automation/playliste in ihr Studio holen und diese Moderieren.
1.Nun ist meine Frage ob man die Berechtigungen auch Transparenter gestalten könnte als das sie schon vorliegen. Ich denke da an Haken die ich setzen könnte was er darf und was er nicht darf etc. Um eventuell versehentlich gespeicherte Playlisten usw zu verhindern. Welche Anforderungen/ Berechtigungen das genau wären müsste ich mal ausarbeiten. Bis jetzt hab ich alle als Moderatoren drin. Dort dürfen sie aber zb keine Cue Punkte bearbeiten das schlecht ist denn so könnten alle daran arbeiten mit Titel Infos etc.
Gibt es eine Möglichkeit zu Loggen was welcher Moderator wann getan hat in der Datenbank?
Da die Datenbank momentan als *mldb läuft mit der dbserver.bat ist die Überlegung diese auf eine SQLite oder dergleichen umzubauen und ob das Sinn macht hinsichtlich Betriebssicherheit und Verwaltung.
(ich meine das die mldb ohnehin eine SQLite ist bin mir aber nicht sicher)
Soweit ich weiß gibt es ein Benutzerrollenkonzept, dass aber Damals nur mit dem PostgreSQL Backend funktioniert hat, weil es auf die Berechtigungsstruktur dort zurückgegriffen hat. Ich weiß nicht, wie das aktuell aussieht. Die Benutzerrollen sind jedenfalls vorhanden und funktionieren:
Wie man ein Datenbank Backend installiert, sollte jeder Server Administrator wissen, daher gehe ich da nicht weiter drauf ein.
Du installierst also z.B. PostgreSQL als Backend und bindest das in Dein mAirlist Professional ein.
Danach exportierst Du die alte Datenbank über den Export Dialog, als CSV und importierst dieses Dokument wieder in Deine neu angelegte Datenbank.
Ich bin ein Datenbank DAU. Bedeutet es, dass die in Mairlist wählbaren Rollen schon in der PostGre DB vorhanden sind? Oder muss mit pgadmin noch was eingestellt werden?
Mit den Postgres Tools habe ich eigentlich bisher nur bei der Installation gearbeitet und anfangs mal zum Backup. Inzwischen ziehe ich lieber Snapshots von dem Linux Container in dem mein Datenbank läuft.
Nein, bitte nicht über CSV. Das ist nur zum Export/Import von Basis-Metadaten gedacht, zum Beispiel um eine externe Musikplanung damit zu füttern, oder als Datenübernahme von Fremdsystemen.
Zum Umstieg auf ein anderes SQL-Backend (wie auch Wechsel zwischen SQL-Server und SQLite) gibt es die Funktion “Datenbank klonen” im Export-Menü der DB-App.
Genau dafür ist es gedacht. Bekanntermaßen haben alle SQL-Backends ihre eigenen “dialektischen” Feinheiten, weswegen ein SQL-Dump von Backend A nicht einfach in ein Backend B eingespielt werden kann. Die Clone-Funktion kopiert wirklich Zeile für Zeile und nimmt noch die entsprechenden Anpassungen vor wo nötig. Dauert halt etwas länger.
Ja, genau das hatte ich dabei im Sinn. Ich dachte dass das klonen dann nur ein SQL Dump ist und das man deshalb die Funktion nur auf dem gleichen SQL Backend nutzen kann.
Das ist echt ein mächtiges Feature.
Ein durchaus wichtiger Stichpunkt der ins Wiki sollte. @UliNobbe eine Rubrik “Quick Tips” wäre vielleicht ganz hilfreich, wo man relativ unsortiert kleine Kniffe unterbringen kann. Da kann man dann immer noch in andere Artikel einfließen lassen.
Hallo shorty,
kannst du mir bitte erklären welche Rolle dem VT DJ vorbehalten ist bzw. dem Unterschied zwischen DJ & VT DJ ?
Vielen lieben Dank im voraus und beste Grüße Addi
nur mit dem PostgreSQL Backend funktioniert hat, weil es auf die Berechtigungsstruktur dort zurückgegriffen hat. Ich weiß nicht, wie das aktuell aussieht. Die Benutzerrollen sind jedenfalls vorhanden und funktionieren:
