Postgres DB

Ich hab nun mal installiert, und dabei gleich mal die Konfig aus 4.4 importiert.

Wie verhält sich das mit der DB ?
bei 4.4 ist das DB schema v. 20
in der 5.0 wird DB v21 benötigt.
kann ich das gefahrlos machen oder ist dann die Ausspielung und Handhabung in der 4.4 nicht mehr machbar ?
Sprich abwärtskompatibel ?

Nein, ist nicht miteinander kompatibel! Sobald du auf Schema 21 bist, kann mAirList 4.x nicht mehr auf die Datenbank zugreifen!

Daher am besten eine Kopie der Datenbank anlegen und diese dann für mAirList 5 aktualisieren.

so, ich hab dann mal eine neue DB erstellt und ein backup eingespielt.
in der mairlist config eine neue DB angelegt und normal eben mit der Kopie verbunden,
auch soweit ok,
aber sobald ich ds DB.schema aktualisiert habe fragt er dann natürlich nach der DB ID Und ob er die automatisch ermitteln soll, auch OK soweit, aber dann kommt

ungültig schema-version gefunden (20 - 21 benötigt, bitte DB aktualisieren)

Mit welchem Build hast du das Schema-Upgrade gemacht? Da gab es einen Bug, der genau zur Fehlerbeschreibung passt. (Upgrade angeblich erfolgreich, aber beim erneuten Test steht wieder die alte Schemaversion da.) Der sollte aber inzwischen behoben sein.

ok, ich hab nun mal letztes snapshoz genommen und drüberinstalliert, nun gings fehlerfrei mit dem schema.

aber, obwohl login in ok ist und es auch keine fehlermeldungenb nach programmstart gab,
gibt es immer die meldung NICHT VERBUNDEN

Hallo torben, du hattest mich per mail gebeten das systemprotokoll nach fehlermeldungen zu durchsuchen,
die einzige fehlermeldung die rot auftauchte war die im andren beitrag genannte CW unable to change…

hinzuzufügen wäre, es handelt sich um eine DB die auf einem anderen PC liegt, (aber eben genau die konfig die unter 4.4. läuft.

  1. PC = Automation (da befindet sich auch die postgres DB drauf)
  2. PC = Livesendungen (greift über das netzwerk auf diese DB zu)

unter 4.4 problemlos

Wird die Datenbank im Datenbank-Browser als verbunden oder als getrennt angezeigt?

ganz normal, ich kann die tracks auch rüber ziehen und sie werden vorgepuffert,
allerdings bei der suche in der DB gibts dann als ergebnis:
Fehler beim Suchen nach DBname: value0

nehme ich einen track aus der DB und pack ihn in den PFLplayer läuft er problemlos.
nur eben in der hauptplayliste geht nix, nicht mal dateieigenschaften… da gibts not connected.
klick ich dann auf OK
geht dateieigenschaften auf aber im cue editor ist nix

Und du hast nur diese eine Datenbank eingebunden? Oder mehrere?

ich habe auch vermutet (2. DB)
hab natürlich die original.DB erst deaktiviert, dann sogar gelösccht in der konfig.
also nur eine

nach neustart geht nun zwar das öffnen der datei aber der genannte fehler in der suche ist immer noch da,

ich denke dass not connected daran gelegen hat, dasss die 2. DB (altes schema) in der konfig eingetragen war, allerdings war sie definitiv deaktiviert.

Ja, genau, daran lag es.

Wenn zwei identische Datenbanken (bzw. Kopieren davon) eingetragen sind, haben die jeweils die gleiche Datenbank-ID. Und wenn mAirList dann versucht zu ermitteln, zu welcher DB ein bestimmtes Element gehört, greift es u.U. auf die falsche Datenbank zu - in deinem Fall die deaktivierte alte Datenbank, die vermutlich weiter oben in der Liste stand.

ok, dann bleibt der fehler in der DB-Suche.

In Build 2507 ein paar Vorsichtsmaßnahmen:

  • Fehlermeldung beim Programmstart, wenn zwei oder mehr Datenbanken mit derselben ID eingetragen.
  • Bei den Element-Eigenschaften werden die Reiter Sendeplanung und Verlauf ausgeblendet, wenn die Datenbank nicht verbunden ist.

Bei der Suche konnte ich bislang keinen Fehler reproduzieren. Schick doch bitte mal einen Bugreport, sollte es bei dir noch einmal auftreten.

hm, der fehler suche ist immer noch, allerdings ist keine möglichkeit auf bugreport gegeben.


Unbenannt-1.jpg

Bug gefunden. Ist nur, wenn man auch nach Attributen sucht (rechte Maustaste auf Eingabefeld, Attribute angekreuzt). Und: Der müsste auch in v4.4 schon drin sein!

Bugfixes folgen in Kürze.

4.4 und 5.0 beide aktualisiert.

prima, was ich nicht verstehe, weshalb haben die 2 datenbanken die gleiche ID, es sind doch 2 verschiedene ?
oder wo ist da mein gedanklicher fehler ?

ich hab nun das problem, dass selbst die aktuell genutzte 4.4 db rumzickt, zwischenzeitlich nicht verbunden ist (wahrscheinlich wenn auf dem anderen PC die 5er gestartet wird ? )
diverse eigenschaften auf einmal nicht mehr anwesend sind, die vorher definitiv da waren, z.b. cover

und nun wird es lustig.
starte ich nur die DB, sind die attritute (z.b. cover) da
starte ich mairlist, und daraus dann die DB, dann teilweise nicht

Du musst verstehen, wie die Datenbank-ID funktioniert und welchen Zweck sie hat.

Die Datenbank-ID ist dieser wirre Hex-String, den du in der Konfiguration unter “Erweitert” siehst. Die ID steht zum einen in der SQL-Tabelle “config” - außerdem ist sie in der database.ini aller mit ihr verbundenen mAirList-Installationen vermerkt. Beim Verbinden überprüft mAirList auch, ob der Wert aus der database.ini mit den Angaben aus dem SQL-Server übereinstimmen, sonst schlägt der Verbindungsversuch fehl.

Die Datenbank-ID ist dann wichtig, wenn mehrere mAirList-Installationen sich eine Datenbank teilen und Daten über diese austauschen. Damit PC B weiß, welche Datenbank PC A meint, wenn er von “der Datenbank” redet. Deswegen muss die ID auch auf allen Installationen identisch eingetragen sein und - im Umkehrschluss - auch in der SQL-Tabelle.

Wenn du die Datenbank auf SQL-Ebene kopierst, kopierst du damit auch die config-Tabelle, und die Kopie erhält dieselbe Datenbank-ID. Wenn du diese Kopie jetzt ebenfalls in mAirList einbindest, dann glaubt mAirList, es sei zweimal mit derselben Datenbank verbunden. Und es knallt.

In meinen Augen macht es auch wenig Sinn, die alte v4-Datenbank deaktiviert in der v5-Konfiguration zu haben. Verbinden kannst du dich mit der sowieso nicht mehr.

Ich hab es so gemacht: Die alte PostgreSQL-Datenbank hieß “mairlist4”. Dann habe ich eine Kopie namens “mairlist5” eingetragen, in der v5-Konfiguration den Namen der SQL-Datenbank entsprechend geändert, und dann ein Schemaupgrade durchgeführt. Jetzt arbeitet mAirList 4 mit mairlist4, und mAirList 5 mit mairlist5.

Gegenseitig beeinflussen tun die sich sicher nicht. Was du da beschreibst klingt so, als hättest du dir die alte Datenbank irgendwie zerschossen, vielleicht durch ein versehentliches Schemaupgrade, das aber irgendwie nur halb ausgeführt wurde? Keine Ahnung.