Hallo allerseits,
wie kann man Standard-Attribute umbenennen?
Schöne Grüße
Martin
Hallo,
also sobald ich in der Konfiguration von mAirList auf Verschiedenes -> Standard-Attribute gehe und dort Doppelklick (oder oben auf Konfigurieren) auf das jeweilige Attribut durchführe, kann ich diesen beliebig einstellen.
Das selbe gilt auch für die Attribute in der Datenbank: Verwaltung -> Konfiguration -> Standard-Attribute
Naja, “einstellen” kann man da was, sagen wir, nach mAirList-Manier. Doof ist nur, dass dann die Inhalte nicht mehr erscheinen. Probiert hatte ich das unter “Verschiedenes”.
Unter umbenennen verstehe ich, dem Attribut bzw. Feld einen anderen Namen geben zu können, ohne die Inhalte zu verlieren.
Zusätzlich würde ich gerne wissen, was es mit den offenbar verschiedenen Stellrädern der Attribute auf sich hat, als da wären:
Standard-Attribute (im config-Verzeichnis “Verschiedenes”),
Standard-Attribute (in DB-Konfiguration)
sowie
Playlist-Attribute (in DB-Konfiguration).
Wie verhalten sich die Einträge untereinander und wann sollte man wo schrauben oder auch nicht? Bei einer großen Datenbank schraubt man da nicht gerne ins Blaue 
Am wichtigsten aber ist mir die Ausgangsfrage!
Wochenende, Brückentag und Feiertag sind rum, da schiebe ich das doch glatt nochmal nach oben 
Korrekt. Darüberhinaus befinden sich 50% der Belegschaft der mAirList GmbH im Urlaub.
Danke für die Erinnerung.
Dröseln wir das mal auseinander.
Ein Attribut ist ein Attribut ist ein Attribut. Klingt doof, ist aber so.
Benenne ich das um, verändere ich, zumindest datenbankintern, einen Wert.
Na gut.
Stellen wir diesen Aspekt zunächst einmal hinten an.
Zu der Sache mit den Standard-Attributen: Ich erinnere dich an einen Thread, in den du dich eingeklinkt hast: Attribute exportieren/importieren
Torben schreibt dort:
Diese “Standard-Attribute” dienen lediglich dazu, die Eingabemaske auf der linken Seite des Eigenschaften-Dialogs (Reiter Attribute ) zu gestalten. Was du als Standard-Attribute definiert hast, erscheint dort links in der hübschen Maske - alles andere rechts in der “dummen” Tabelle.
Und weiter:
Man kann die Attribute sowohl in der Konfiguration definieren (dann sind sie nur lokal für diesen PC wirksam) oder in der Datenbank (DB-App → Verwaltung → Konfiguration), dann werden sie automatisch auf allen mAirList-Instanzen aktiv, die mit dieser DB verbunden sind. Außerdem erscheinen sie dann auch als zusätzliche Spalten in der DB-App.
Quelle: Attribute exportieren/importieren - #16 by Torben
Ich rate zur Konfiguration in der DB. Bei einer lokalen DB brauche ich die Konfiguration (“Verschiedenes”) von mAirList selbst nicht, solange ich als Client keine weiteren Zugriffe auf externe Datenbanken habe.
So, und jetzt zum Standard-Attribut, das du umbenennen möchtest.
Wenn ich schreibe, “Ein Attribut ist ein Attribut ist ein Attribut”, dann hat das seinen Grund.
Streng genommen müsstest du das Attribut im ID3-Tag bzw. Vorbis Comment ändern und dann die Metadaten neu einlesen.
Bleiben die Metadaten gleich, kannst du zwar das Standard-Attribut ändern, aber was soll das bringen?
Mag ja sein, dass ich es noch nicht verstehe, aber ich zeige dir mal ein Beispiel:
Hier habe ich ISRC in ISRD umbenannt. Folge: Das Attribut bleibt und wandert, wie von Torben formuliert, nach rechts in die “dumme” Tabelle und das Standard-Attribut “ISRD” bleibt leer. Schließlich gibt es ein solches Wertepaar in den Metadaten nicht.
Hilft dir das weiter?
Solltest du etwas anderes im Sinn haben, kläre mich bitte auf.
Das hatte ich nicht mehr auf dem Schirm. Danke, das bringt Licht in meine Zusatzfragen. Werde ich umstellen auf “in der DB”!
Jetzt versuche ich aufzuklären, warum ich ein Standardattribut umbenennen will. Der Hauptgrund ist, dass mir der aktuelle Attributname (“Lagerort”) zu lang ist. In diesem Feld steht die Regalfachnummer des jeweiligen Tonträgers (z.B. “LP17”). In der DB-Tabelle möchte ich die Spalten möglichst schmal halten. Passe ich sie in diesem Beispiel an den Inhalt an, erscheint in der Überschrift “Lage…”. Deshalb soll das Attribut “Lager” oder “Regal” heißen oder “Ort”. Ich müsste also, um diese Umbenennung zu erreichen, sämtliche Datensätze aktualisieren und den Feldinhalt per csv-Import in das neue Attribut zu schreiben? Da ist der Rechner wieder einen Tag lang blockiert. Ähnlich wäre es, hätte man sich bei Anlegen vertippt.
Es handelt sich also um Attribute, die du nur in der Datenbank angelegt hast und die nicht Bestandteil der Metadaten des Musiktitels sind?
In dem Fall lässt sich tatsächlich der Name des Attributs verändern (ob jetzt Standard oder nicht, spielt keine Rolle).
Über die Massenbearbeitung ist das leider ein wenig tricky und möglichwerweise fehlerbehaftet. Vor allem, wenn die Werte mit den Attributen sehr verschieden und vielfältig sind.
Vielleicht kennt Torben den Trick über die SQL-Konsole in der Datenbank.
Da bin ich aber 'raus.
Und mittels csv?
Denkbar, wäre einen Versuch wert.
-
Du legst bei einem Element einfach ein neues Attrbut an und füllst es mit einem Dummy (rechtes Feld, Cursor nach unten und in die leere Zeile Attribut und irgendein Füllsel eintragen).
-
Beim csv-Export entsteht jetzt auch eine Spalte mit dem Attribut.
-
In der Tabellenkalkulation kannst du nun die Inhalte der bisherigen Attribut-Spalte in die neue Attribut-Spalte kopieren.
Beim Import der csv-Datei sind jetzt zwar die neuen Attributnamen gefüllt, aber die alten nicht verschwunden.
Das wiederum geht mit einem Trick in der Massenbearbeitung, zu dem man jedoch nur mit Bedacht greifen sollte.
Im csv-Import bin ich geübt Das mache ich fast täglich - aber nur im Bereich von zwei- bis dreistelligen Mengen.
Den Komplett-Import kann ich natürlich mit neuem Attributnamen machen. Aber bei rund 200-tausend Datensätzen ist das dann echt eine Frage der Zeit. Da überlegt man sich jedes hin- und herschieben dreimal.
Und dann noch in mAirList aus dem alten Attribut die Daten per Massenbearbeitung entfernen (incl. “…seems to be frozen”-Meldung) ist ja auch nicht in zehn Minuten getan. Deshalb hätte ich das gerne vermieden.
Das wäre toll, aber leider nur mit Schritt für Schritt-Anleitung umsetzbar…
Bisher mache ich das so:
In der Massenbearbeitung wähle ich das zu leerende Attribut, klicke in das Wertefeld, lasse es leer und dann auf die beiden OKs. Und die Rödelei nimmt ihren Lauf.
Geht das mit dem “Trick” einfacher und schneller?
Mit Datenbanken dieser Größenordnung habe ich keine praktische Erfahrung.
Schneller nicht, nein.
Dass die mAirListDB in v7 etwas schneller geworden sein dürfte, sollte sich gerade bei solch großen Datenbanken bemerkbar machen. Aber spezifisch beim löschen von Attributen? Nicht, dass ich wüsste.
Als ich das letzte Mal Attribute gelöscht habe, habe ich, im Gegensatz zu dir, zu zwei Schritten gegriffen. Das Leeren des Wertefeldes allein schien nicht erfolgreich zu sein.
Vielleicht liegt es daran, dass ich mehrere verschiedene Attribut-Werte auf einmal gelöscht haben wollte?
Zwei Schritte? 
-
Nach Auswahl des Attributs habe ich in das Werte-Feld ein Leerzeichen eingetragen und auf Anwenden geklickt.
-
Erst danach habe ich das Leerzeichen als Wert gelöscht und das leere Feld mit Anwenden übernommen sowie mit OK in die Datenbank geschrieben.
Ob Schritt 1 immer noch notwendig ist? Müsste ich mal austesten.
Könnte nicht schaden. Aber, ich weiß, mAirList ist dafür nicht gemacht.
Haben Torben oder ich das irgendwo beleghaft behauptet?
Falls ja, habe ich das gerade nicht auf dem Schirm.
Eine Quelle wäre hilfreich. Danke.
Das war klar und deutlich. Deshalb arbeite ich jetzt schon an einer Exit-Strategie.
Ja, danke. Das hatte ich so wirklich nicht mehr im Hinterkopf.
Ich kann jetzt nicht darlegen, inwieweit mAirList selbst hier an Grenzen stößt (das weiß nur der Hüter des Codes selber) oder ob es am Datenbanktyp liegt.
Ob deine Zeit, Geduld und Experimentierfreude für einen Vergleich mit z.B. PostgreSQL ausreicht? In dem Fall einfach mal über den Support Kontakt aufnehmen, und wir finden einen gemeinsamen Weg.
Das hatten wir seinerzeit schon durchexerziert - ohne nennenswerten Erfolg.
Ich habe mich inzwischen ja an das Exotendasein hier gewöhnt. Wäre schön gewesen, wenn das mit dem Umbenennen geklappt hätte. Ich mache mir keine weiteren Hoffnungen und löse es per workaround.