Posts by Minotaurus007

    Ergänzung 2: MySQL-Update 5.0.14-nt -> 5.1.49 ist ursächlich für #23000Duplicate-Entry-Exception fuer key "group_key".


    Da ich wirklich ein Restore durchgeführt habe, ohne eine bestehende DB zu überschreiben, trifft der von Kai genannte Thread hier nicht zu. Ich erinnerte mich, dass ich vor ein bis zwei Wochen auch mein NAS (Synology DiskStation) aktualisierte mit dem DSM 3.0. Dort erfolgte auch ein Update der dort laufenden MySQL-Version.
    In mir schwante also, dass weder Kai (nie nicht!), noch Imabas 8.1 "Schuld" an dem DuplicateEntry-Schock sind, sondern vielleicht MySQL?!


    Nichts einfacher zu testen als das! Ich sicherte die aktuelle Datenbank von Imabas 8.1 (MySQL 5.1.49 auf DiskStation mit DSM 3.0) mit MySQL-Administrator und spielte sie mutig auf einen Rechner, der noch MySQL 5.0.14-nt laufen hat. Dort startete ich dann die Abfrage, die zu o.g. Exception führte: und jetzt sie läuft erfolgreich durch! (Sie braucht übrigens mehrere Stunden, wenn der Rechner nur 500 MB RAM hat.)


    Interpretation: entweder MySQL hat einen Bug bei seinen "group_key"s eingeführt, oder MySQL wurde verbessert und findet einen Fehler in meinem Query-String (was natürlich gar nicht nie nicht sein kann... grins).


    Fazit: Komplexe Abfragen (mit GROUP BY und HAVING und COUNT) können nach einem MySQL-Upgrade von 5.0.14-nt auf 5.1.49 zu einem Duplicate-Enry Error #23000 error für den key "group_key" führen. Dabei erstellt MySQL vermutlich eine temporäre Tabelle, in der die Goups einen Group_Key erhalten. Denn weder ich (in meiner Query) noch Kai (in den Imabas-Tabellen) haben einen Key / ein Feld "group_key" definiert.
    Denkbar ist, das bei Bereichsbegrenzungen des group_key Probleme bei Gigabyte-großen Tabellen eingeführt wurden. Es könnte passieren, dass weitere Imabas-Power-User auf diesen Error stoßen.


    Konsequenz: Hier liegt ein MySQL-Problem vor, eingeführt durch ein Versionsupdate.
    Ich werde versuchen, meine Query zu ändern. Zu meiner Freude kann ich erst mal ohne die befürchtete Neueingabe von Datensätzen in eine saubere DB locker mit V 8.1 weiterarbeiten. Ob ich mich in die MySQL-Foren reintraue, möchte ich allerdings bezweifeln... ;-)


    -Mino

    Ergänzung zum Posting von vorhin:


    Ich habe die aktuellen drei Tabellen, in denen ich die Abfrage durchführe, die zum #23000DuplicateEntry-Error führt, auf duplicate entries im ukey überprüft mit


    Select count(*)
    From bilder // [auch überprüft: attrobjgroups, attrobjdata]
    Group by ukey
    HAVING COUNT(*)>1;


    Keine DuplicateEntries zu finden. Das Argument, dass durch fehlendes Löschen zusätzliche doppelte Datensätze beim Restore entstanden sind, gilt also (leider) nicht.


    -Mino

    Das sind ja schöne Aussichten. Ich habe natürlich fleißig weitergearbeitet mit den Tabellen. Wenn ich die Datenbank, die die Fehlermeldung bei Abfrage gibt, jetzt sichere und dann in eine "saubere" neue DB einspiele, habe ich doch nichts gewonnen, oder? Ich muß also die DB von V 7.2 wieder einspielen? Da sind also einige Tage Arbeit hin...


    Ist das wirklich so?


    Ich hatte natürlich nach dem Backup von V 7.2 und vor dem Restore meine Datenbank V 8.1 gelöscht mit dem MySQL-Administrator. Reicht das nicht? Sie war jedenfalls in der Schema-Liste nicht mehr sichtbar.


    Eine Suche nach duplicate entries dürfte wesentlich einfacher sein...


    Ich werde daher folgendes machen: eine der Sicherungen, die sicher noch funktionierten, werde ich zurückspielen in eine ganz neue DB mit anderem Namen und dann die Query testen. Ich berichte dann erneut.


    -Mino

    So, der Löschvorgang ist jetzt fast perfekt. Das mit der Bestätigung suggeriert zwar noch, dass man nur ein Bild löscht, aber das ist kein wirkliches Problem.


    Es sollte jetzt noch das gute alte STRG+A zum Multiselect implementiert werden. Das SHIFT+Klick ist längst nicht so elegant. STRG+A funktioniert ja auch sonst überall in Imabas. Ist für den Programmierer bestimmt nur ein Klick auf irgendeine Property. :e045:


    -Mino

    Hintergrund: als ich die V 8.1 ausprobierte, stolperte ich über einige Bugs, die Kai zwischenzeitlich zügig korrigiert hat. Ich mußte aber zunächst wieder auf V 7.2 zurückgreifen und spielte die gesicherte Datenbank mit MySQL-Administrator wieder zurück. V 7.2 lief, viele Abfragen auch. Bis auf eine.


    Ich bekomme jetzt folgende Fehlermeldung:


    #23000DuplicateEntry '4D71...' for key 'group_key'


    Das Interessante ist, dass der Fehler auch schon in V 7.2 passiert, also nichts mit dem Upgrade auf V 8.1 zu tun hat. Ich habe ihn nur noch nie erlebt, weil ich bislang noch nie eine Datenbank zurückspielen mußte. D.h. beim Zurückspielen muss irgendetwas verändert worden sein, was zu diesem Fehler führt. Dabei ist die 32byte VARCHAR sicher nicht doppelt vorkommend. Zumal dies - wenn ich mit der Datenbank weitergearbeitet habe - regelmäßig mit anderen Entries (VARCHAR(32)) auftritt, die unmöglich alle doppelt vorkommen können.


    Ich vermute also, irgendwelche Tabelleneigenschaften wurden beim Zurückspielen stillschweigend mit MySQL-Administrator geändert. Aber welche könnten das sein?


    Weiss Kai vielleicht auch, wo der key "group_key" herkommt, den finde ich nämlich nicht in den zig Tabellen von Imabas? Ich selbst habe diesen key-Namen auch nicht in meiner Abfrage definiert.


    Zu ergänzen ist, dass im Web der #23000DuplicateEntry-Error bei backup/restore immer wieder beschrieben wird und etwas zu tun haben könnte mit dem Zeichensatz (UTF8 ). Er wurde auch beschrieben bei auto-increment Feldern, die eigentlich auch keine duplicate entries haben dürften. Zudem sind die ukey's von Kai keine Auto-Increments.
    Hier aber dürfte weder der Zeichersatz eine Rolle spielen, da es sich um eine 32byte Varchar handelt (also einen "ukey"), noch dürfte es sich um eine "wirkliche" Kollision handeln, weil die identische Abfrage (Query) vor der backup-restore-Prozedur via MySQL-Administrator stets problemlos lief.


    Was hat MySQL-Administrator verbrochen? Hat jemand oder Kai eine Idee?


    -Mino


    ps: Meinen Query-String möchte ich den Lesern hier ersparen, sende ich bei Bedarf aber mit PM gern zu.

    Ich habe noch nicht gefunden, wie man das Programm ordnungsgemäß verläßt. (Früher Menü > Datei > Beenden). Hier klicke ich auf das "X" rechts oben zum Schließen eines Fensters. Dann crasht das Programm mit etlichen Exceptions und den Wunsch, den Error an Microsoft zu melden, wie üblich. Ich klicke alles so lange weg, bis Imabas Ruhe gibt. In mir ergibt das Unruhe.


    Aber einen Crash des ganzen Rechners habe ich nicht. Ein Neustart des Programms funktioniert auch ohne Macken. Aber diese neue Oberflächengestaltung (MS-Vorgabe?!) ist leider alles andere als intuitiv und sehr gewöhnungsbedürftig.


    Ich mache es so, dass wenn ein Update läuft ich frühestens nach einem Jahr wieder update, um meinen restlichen Haarbestand zu wahren.


    -Mino


    Never surrender!

    Jetzt wollte ich mal die neue Funktion testen: Export komplett mit einem Klick löschen, doch sooo weit komme ich gar nicht. Nach Rechtsklick > Ausführen lächelt micht freundlich eine MessageBox an:


    Datensatz gesperrt!
    Das angeforderte Objekt ist zur Zeit gesperrt.
    Bezeichnung: (Name des Exports)
    Benutzer:
    Gesperrt am: 11.11.10 - 00:29:39

    Was kann ich tun um die Sperrung aufzuheben und weiterzuarbeiten? Ausser bis in die Nacht mit dem Programm zu kämpfen?


    -Mino

    Ich habe mich - mit ungutem Gefühl - getraut, auf V 8.1 upzudaten.


    Erste weniger gute subjektive Eindrücke gegenüber V 7.2:
    - deutlich langsamer als Vorversion
    - Finde meine gespeicherten Recherchen auch nach 20 Minuten Suche nicht. Wo sind sie jetzt versteckt? Oder gar abgeschafft?
    - Ribbon-Technik raubt enorm viel Bildschirmfläche, und das bei einem Bild(datenbank)-Programm.
    - Ribbon "verkleinern" blendet nur das Ribbon aus, gibt aber nicht mehr Platz zum Arbeiten frei. Somit ist es kein "Verkleinern". Deutliche Verschlechterung gegenüber 7.2.
    - Bilder werden beim Import immer noch nicht automatisch gedreht, so dass sie "richtig" stehen. Muss das also weiter mit der Hand machen. Wo ist das Problem?
    - ... tbc ...


    Doch nun kommt es:


    Ich will meine Attributvorlagen zuweisen wie immer. Doch Zahlenfelder, die mit einer 0 (Null) vorbesetzt werden sollen, können nicht mehr eingelesen werden. Fehlermeldung: "Pflichtfelder ausfüllen!"


    Es waren immer Pflichtfelder, und V 7.2 hat die Nullen korrekterweise auch akzeptiert.


    Ich könnte nun die Pflichtfelder umprogrammieren auf "nicht-Pflichtfeld". Doch wer weiss, was dann mit dem bisherigen Datenbestand passiert... also lieber nicht.


    Fazit: V 8.1 muß - bei mir - leider wieder runter. :-(


    Gibt es eine andere Lösung?


    -Mino

    >Hintergrund ist das die Attributdaten als String gespeichert werden


    Da muß man erst mal drauf kommen, wo ja sogar die Attribute als "Zahl" und sogar mit "Anzahl Dezimalstellen" angelegt werden... In MySQL kann man die Daten doch locker als Zahl ablegen, dann dürfte auch die Abfrage ohne CAST wirken.


    Aber ich sehe, ich komme jetzt um ein Update endgültig nicht mehr herum. Was mich aber doch wundert, ist, dass da noch niemand drauf rumgemeckert hat! Arbeitet hier niemand mit Attributen...?!


    Vielen Dank! :-)
    -Mino

    Ich erstelle eine Attribut-Gruppe Shooting mit Attributen (Text, Zahlen, Auswahl):


    • Geschlecht: m/w/unbekannt
    • Kategorie: Portrait/normal/.../unbekannt
    • Rating: (Zahl, 2 Dezimalstellen)
    • nRating: (Zahl, 0 Dezimalstellen)
    • ...


    Eine Shooting-Vorlage 1 besetzt die Einträge vor, um bei riesigen Bilderserien die Attributzuweisung zu erleichtern, z.B.:


    • Geschlecht: weiblich
    • Kategorie: Portrait
    • Rating: 1500 (eine von mir vorgegebene Zahl, mit 2 Dezimalstellen)
    • nRating: 0 (Anzahl der Bewertungen eines Bilds (Zahl, 0 Dezimalstellen))
    • ...


    (Eigene Software nutzt nun diese Datenbankeinträge um Bilder zu bewerten, was mit Imabas nicht gut möglich ist. So erhalten die Bilder nach und nach eine Bewertung; z.B. Rating 1859,39 bei nRating 5 (=5x bewertet).)


    Eine Recherche nach Bildern mit einer Zahl als Attribut gelingt nun nicht, bzw. bietet erstaunliche Auffälligkeiten:


    Recherche-Einstellungen:


    • Attribut nRating 0 bis 5 -> findet nur Bilder mit nRating = 0
    • Attribut nRating 0 bis 0 OR 1 bis 1 OR 2 bis 2 ... 5 bis 5 -> findet nur nRating = 0
    • Attribut nRating 2 bis 3 -> findet NUR nRating 20 bis 29 (! - grosse, aber vielleicht hilfreiche Überraschung!)
    • Attribut Rating 900 bis 1200 -> findet nichts (obwohl vorhanden)
    • Attribut Rating 1100 bis 1200 -> funktioniert! Findet Bilder mit Rating zwischen 1100 und 1200; auch Suche nach 1800-3000 funktioniert.


    Bin mir nicht sicher, welche Auffälligkeiten diese Recherche noch bietet. Sie kommt mir aber buggy vor. Aus Programmierer-Sicht könnte vielleicht ein 0-terminierter String die Ursache sein?!


    Der Guru ist gefragt!


    -Mino
    --
    V 7.2

    Oh ja, Multiselect wie beschrieben ist möglich. Aber zumindest in V 7.2 (ich bemühe mich, 1x im Jahr zu updaten :-) ) führt ein anschließendes Klick auf das Lösch-X dazu, das brav alle 500 Pix einzeln bestätigt werden müssen. Also resultieren 500 Klicks. Ich dachte, das ist eine Sicherheitsmaßnahme von Programmseite, um nicht 500 Pix versehentlich zu killen, die ja immerhin auch im Zielverzeichnis dann gelöscht werden.


    Aber wenn man sich wirklich sicher ist, kann man eben (mit V 7.2!?) nicht alle löschen sondern bleibt, wie in meiner Ursprungsmail beschrieben, auf 500 Klicks sitzen. Klar, ich weiß, dass ich auch zu Fuß ein Verzeichnis löschen kann. Aber wenn man ein File löschen kann, und sogar multi-selecten kann, liegt so ein Massen-Kill einfach intuitiv sehr nah. Vielleicht klappt's ja?!


    - Mino

    Den Export zu kopieren - wieder eine Möglichkeit gelernt. Doch leider ist es nicht ganz das, was ich will. Denn das Löschen der Bilder löscht ja komfortablerweise auch das Bild des Exports. Und ich hätte eben gern auf Knopfdruck die exportierten Pix alle entfernt.


    Anwendung: Webseite. Z.B. Export BestePix. Nach einem Monat hat sich die Rangliste verändert. Ich will nun die aktuellen besten Bilder auf Knopfdruck exportieren, muß dabei aber die alten löschen.


    Aber nochmal, wenn man ein Bild wählen kann, was so behandelt wird, wie ich es gern hätte (aus Export und aus Zielverzeichnis gelöscht), warum geht das dann nicht mit mehreren / allen?


    Aber ich gebe mich erst mal zufrieden, dachte nämlich, hab irgendwas übersehen. Beste Grüße


    -Mino

    Wenn du den "Ausführen"-Dialog öffnest, auf der ersten Seite (Bilder), da wo du die Bilderchen alle sehen kannst, gibt es eine Schaltfläche "Entfernen", versuch mal ob das das ist was du meinst... :g015:


    Gruß, Kai


    Das funktioniert in der Tat aber nur für jeweils ein Bild. Will man z.B. einen Export von 500 Pix löschen, muß man tatsächlich 500 x klicken. :-(


    Das klassische STRG+A um alle Bilder der Liste auszuwählen und dann zu löschen - von mir aus mit Sicherheitsbestätigung - sollte einfach zu implementieren sein und wäre sehr benutzerfreundlich.


    -Mino

    Aufgabe: Datenbank-a (DBa) und DBb mit gleicher Struktur, jeweils auf eigenem Server und Datenbankserver.


    Ich möchte nun selektiv Bilder von DBa nach DBb kopieren oder verschieben. Dabei sollen


    • alle Standort-, Personen- und umfangreiche Attributdaten übergeben werden
    • die Originale in ein Verzeichnis auf dem DBb-Rechner kopiert werden



    Sinn ist, nicht alle komplizierten Attributdaten per Hand neu eingeben zu müssen.


    Also entweder ist das ganz leicht oder ganz schwer, dieses Gefühl beschleicht mich... :?:


    Weiss jemand zufällig ob und wie das geht?


    Zufrieden wäre ich auch schon mit einem Neu-Import der Bilder in DBb, wenn dann die Attributdaten von DBa irgendwie übernommen werden könnten.


    Gutes Neues Jahr!
    -Mino

    Gelöst: hab' grad mal die Filmzahl per Hand eingegeben. Imabas kann offenbar mehr als die suggerierten [9999] Filme. Erleichtert guck. Tippe mal, es zählt automatisch hoch, wenn man diese "Grenze" überschreitet.


    [ Rechtsklick auf Filme | Neuen Film anlegen | Nummer ... ] eingeben.


    Habe dann versucht: 999999999 einzugeben -> klappt
    aber 9999999999 -> klappt nicht!


    Imabas ist also auf 1 Milliarde Filme begrenzt. Ehrlich gestanden, mir reicht das...


    Mino