Moin…Nachtrag:
Bei mir arbeitet die Mairlist DB, gebe ich jürgen oder juergen ein, bekomme ich unterschiedliche Ergebnisse.
Gebe ich JÜRGEN ein, setzt der Browser JÜRGEN auf jürgen, macht also aus groß=Kleinschrift. das mit Return bestätigen liefert Ergebnisse.
JUERGEN liefert direkt Ergebnisse, in dem Auswahlfenster wird direkt auf klein gesetzt und gesucht…Kurios das ganze…
Bin ich froh, dass ich keinen Jürgen in der Rotation habe ;D ;D
Das habe ich auch beobachtet, dass das zurückgesetzt wird aber gesucht wird nach dem richtigen Begriff, der tatsächlich eingegeben wurde.
National betrachtet mag das nach einer “Lösung” aussehen, aber mAirList ist ja nun mal eine weltweit vertriebene und eingesetzte Software. Und da gibt es viele Sprachen, die Sonderzeichen aufweisen - der gesamte skandinavische Raum, Frankreich, Spanien, Portugal, Türkei, Trema in de Nederlandse spelling 8) …
… nicht zu vergessen: Der arabische Sprachraum (in dem ich mich nicht hinreichend auskenne) - wird ja auch in der Konfig berücksichtigt mit “[tt]Optimierung für linksläufige Sprachen[/tt]”.
Von daher ist eine Datenbank-Suche unter Berücksichtigung von Sonderzeichen - ganz gleich, welche - meiner Meinung nach ein elementarer Bestandteil des Programms und hat eine große Bedeutung weitab jeglicher “Jürgens”. ;D
Randnotiz:
Da ich für einen befreundeten DJ die Pioneer-Datenbank rekordbox pflege und an dieser Struktur regelmäßig verzweifle (wenn ich graue Haare bekomme, nenne ich die Farbe “Pioneer” :
), weiß ich den mAirList-Komfort durchaus zu schätzen. In der rekordbox muss ich nämlich regelmäßig alle Umlaute, Accents etc. auskehren, weil sonst a) die Sortierung und b) die Suche am Player (die keine Umlaute kennt) sofort kapituliert.
Beim von Martin zu Beginn des Threads erwähnten Beispiel wäre der Suizid der rekordbox vorprogrammiert: Umlaut und Punkt - das geht gar nicht.
Ich hatte bei mir auch schon nach der EAV bzw. E.A.V. gesucht, aber die Freunde sind bei mir ausgeschrieben… 8)
Martin erinnert mich übrigens an meine Anfänge des digitalen DJ’ings - damals mit BPM Studio. Das Programm hat zwar alle Tags in jeder Schreibweise gefressen, aber wenn man einen ID-Tag im Programm geändert hat, wurde der konsequent IN GROSSEN BUCHSTABEN zurückgeschrieben / gespeichert. :o
Nachtrag:
Habe Gestern eine Neue Datenbank mit Build 3930 erstellt (hatte vorher mit einer erstellten aus 6.0.9 gearbeitet), und getestet. Die Gleichstellung ä=ae, ö=oe, ü=ue, egal ob groß oder klein haut nicht hin. Effekt also wie vorher.
Ich erstelle gerade eine Datenbank mit Sam, Importiere die mal nach Mair, um zu sehen ob der Effekt der gleiche bleibt.
Dauert aber ein wenig, wegen der Menge…
“Meinten Sie: ‘mAirList’?” ;D 8) 
Japp…sry…Heute schon so viel getippert da wird man faul… 
So…leider hatte ich Übersehen, das es mit Sam 4…DB geht, die Version habe ich nicht, daher fällt der Test flach…allerdings besteht das Datenbank Problem bei Sam genauso!!!
Gerade getestet…die DB mit Sam erstellt und bei Eingabe ä,ö,ü genauso unterschiedliche Ergebnisse wie bei Mairlist, also ist es nicht einmal ein Mairlist Bug!
Einziger Unterschied bei Sam, dort ist es egal ob groß oder klein, das liefert immer die gleichen Ergebnisse (ich meine damit AE=ae,OE=oe, etc pp), aber die Gleichsetzung Ä=AE erfolgt auch hier nicht.
(Info Sam 2018, DB= Firebird)
Jemand eine Idee?
Ich habe für mich beschlossen, das Problem anders an zu gehen.
Ich werde meine Datenbank (Rohdaten auf Platte), auf Schreibfehler Prüfen, und alles dementsprechend Anpassen.
Per Script hätte ich zwar schnell alle Files Umbenannt (ae gegen ä ausgetauscht, etc. pp), aber das macht keinen Sinn, da es Interpreten wie Aerosmith, oder Blue System gibt, da hätte man nur neue Fehler eingebaut…schließlich Suche ich im Normalfall mit der richtigen Schreibweise…
Wenn dann alles korrigiert ist, wird eine neue Datenbank erstellt und fertig…
Hier mal ein kurzer Zwischenstand, bin fast fertig mit Durchgucken, hat mit MP3-Tag ca. 30m gedauert, die Interpreten Suchen und Korrigieren. Titel habe ich noch keinen Fehler gefunden…da ist es fast zu Schade weiter bei der Datenbankprogrammierung zu Suchen, da es ein grundlegendes Problem zu sein scheint…
Sorry, wenn ich dieses Thema wieder nach oben hole.
Mir ist nur gerade in den Sinn gekommen, ob vielleicht das hier
auch die Ursache für das Problem beim suchen mit Umlauten sein könnte.
Nur so eine Idee. Vielleicht liege ich da ja auch vollkommen daneben.
Nein, das Filtern während der Suche übernimmt der SQL-Server. Auch hier wieder das Stichwort: collation überprüfen.
Und wie geht das mit mAirList? Habe per Suchfunktion nichts dazu gefunden.
Betreibst du eine Netzwerk-Datenbank, z.B. PostgreSQL?
Dann dort.
Nein, die “ganz normale” mAirListDB (local mode).
Okay, nach Rücksprache mit Torben: SQLite ist an manchen Stellen ein eingeschränktes System.
Zitat aus dem “Maschinenraum”:
Es kann von sich aus nicht mit Umlauten umgehen.
Sorry.
Heißt also, mit anderen Worten: bleibt so?
Aktuell: Ja.
Soweit ich das verstanden habe, könnte Torben da vielleicht händisch was umstricken, aber der Programmieraufweind scheint enorm zu sein und ist angesichts knapper Ressourcen derzeit nicht zu realisieren.
Ich will ja nicht schon wieder auf der Pandemie 'rumreiten, aber als Familienvater leidet die Produktivität aktuell doch enorm: Da hast du zwei Kinder an verschiedenen Schulen, und beide rufen wegen Infektionsverdacht in den jeweiligen Klassen sowie entsprechendem Kontakt Quarantäne mit Homeschooling aus.
Bis auf vielleicht mal eine, maximal zwei Stunden am Tag liegt damit die Programmierarbeit an der mAirList-Weiterentwicklung bis auf weiteres brach. Trotz Impfung, Vorsicht, Rücksichtname, Testung…
Ich bewundere den Geduldsfaden der gesamten Familie; das kann ich als Single in dieser Intensität gar nicht genügend nachvollziehen und würdigen.
Euch allen wünsche ich, dass ihr gut und gesund durch die Nummer kommt. Mir sind bereits erste Long-Covid-Fälle im mAirList-Universum bekannt geworden, trotz aller Vorsicht.
Für einen Rundfunkmacher mit Herzblut muss das eine Horrorvorstellung sein.
Das ist bitter. Da bin ich doppelt froh, dass wir in meinem Job in der Anstalt von Beginn an auf Sicherheit fahren und das auch bisher nie zurückgenommen wurde.
Man kann nur hoffen, dass es einen nicht trifft…
Jetzt nochmal zur Sache:
so weiß man wenigstens, woran man ist. Und als selbstfahrender Nicht-Scheduler muss man also weiterhin darauf verzichten, mal schnell nach “ärzte” oder “über den wolken” zu suchen…
Kurze Erläuterung hierzu: In der SQLite-DLL sind tatsächlich keinerlei “sprachspezifische” Funktionen enthalten, da sie die DLL sehr aufblähen würden. Deswegen weiß SQLite von Haus aus nicht, dass ein ü ein ü ist, und der zugehörige Großbuchstabe das Ü.
Es besteht theoretisch die Möglichkeit, solche “Collations” auf Anwendungsseite zu implementieren. Also String-Vergleichsfunktionen in der mAirList.exe, die die sqlite3.dll dann mitbenutzt.
https://www.sqlite.org/c3ref/create_collation.html
Ich weiß aber aktuell nicht, ob die von mir benutzte Wrapper-Library das unterstützt. Außerdem müsste jedes betroffene SQL-Query mit einem passenden COLLATE-Clause versehen werden, damit die Collation dann auch wirklich benutzt wird. Und zwar mit jede Menge IFDEF drum herum, damit es wirklich nur bei SQLite verwendet wird und nicht etwa bei z.B. PostgreSQL, das damit nichts anfangen kann und Fehler ausspucken würde.
Alles in allem eine ziemliche “Aktion”, wie wir hier im Ruhrgebiet sagen würden.