Erneut: Anzahl der Elemente gelesen / ungelesen stimmt nicht

    Leider scheint es - zumindest bei uns - in der aktuellen Build immer noch oder schon wieder (?) Probleme mit dem Zählen der Elemente in den Gruppen/Filtern zu geben.


    Evtl. in diesem Zusammenhang von Bedeutung: Ich habe den GH vor knapp 2 Wochen vom Host Europe Server zu uns lokal umgezogen und dabei auch die MySQL-DB extern angelegt - also wir nutzen nicht mehr die embedded version.


    Ich hatte schon letzte Woche das Problem, dass plötzlich alle Elemente als ungelesen markiert waren und hatte dann (mittels phpMyAdmin) ein Repair über alle Tabellen der Datenbank laufen lassen und dann war alles wieder okay. Hatte es dann darauf geschoben, dass möglicherweise beim Umzug der DB irgendwas schräg gelaufen sei und mir nix weiter dabei gedacht.


    Heute morgen dann dasselbe Problem wieder. Diesmal habe ich zunächst den GH-Server gestoppt und habe dann im GH-Admin unter "Wartung" zunächst die Prüfung durchgeführt. Ergebnis: angeblich alle Tabellen okay - aber leider keine Veränderung im Client. :(


    Also habe ich dann im GH-Admin (nach Stoppen des Servers) mal die DB-Optimierung durchgeführt. Anschließend sah es bei den Filtern so aus:


    Bei den Gruppen sah es so aus:


    Da das ja nun noch nicht so wirklich dem entsprach, was ich gerne gesehen hätte, habe ich dann auch via GH-Admin auch das "Reparieren" mal laufen lassen. Bei den Gruppen hatte sich dadurch gar nichts verändert, die Filter sahen anschließend so aus:


    In Erinnerung daran, dass letzte Woche das Repair via phpMyAdmin geholfen hatte, habe ich dann auch das noch mal probiert - und siehe da:




    Kann das Problem mit unserer lokalen MySQL-DB zu tun haben? Wenn ja: was muss ich checken? - Wenn nein: was ist es dann??

    Hallo,


    das Problem ist hier wohl, dass wir so ein Verhalten bisher nicht beobachten konnten. Das das Problem nach Reparatur im GREYHOUND Admin nicht behoben werden soll, aber per phpMyAdmin schon, kann ich mir so nicht vorstellen. Sowohl GREYHOUND als auch MySQL verwenden die REPAIR Statements von MySQL. Der Weg ist also der selbe. Ich vermute mal, dass nach dem Starten von GREYHOUND im einen Fall länger gewartet wurde als im anderen Fall. GREYHOUND aktualisiert nach dem Start die Ordnerzahlen nach und nach neu, weil diese sich z.B. durch arbeiten an der Datenbank geändert haben können.


    Schließen Sie bitte auch aus, dass es sich um das hier Greyhound Client friert ein nach Standby beschriebene Problem handelt.

    dg_og schrieb:


    das Problem ist hier wohl, dass wir so ein Verhalten bisher nicht beobachten konnten.


    Hmm ... - das ändert aber nichts daran, dass es hier definitiv vorliegt. Ich will ja gar nicht ausschließen, dass es evtl. irgendwelche lokalen Besonderheiten sind, die das beeinflussen - nur bräuchte ich auch dann Hilfestellung, um die Ursache herauszufinden. Denn mit dem Wissen darum, wie dieses Zählen der Elemente funktioniert ist die Ursachenforschung vermutlich einfacher.


    Davon ab nutzen wir hier MySQL täglich für zig andere Sachen. Willl sagen: das Betreiben eines MySQL-Servers ist hier kein Neuland und alles, was mir an möglichen Ursachen so eingefallen ist, habe ich auch bereits gecheckt.


    Das Phänomen ist halt sehr lästig und behindert den täglichen Arbeitsalltag doch gewaltig. Wenn man sich auf die angezeigten Zahlen nicht verlassen kann - besonders auf die gelesen/ungelesen Markierung - dann ist das schon recht behindernd.


    Zitat


    Das das Problem nach Reparatur im GREYHOUND Admin nicht behoben werden soll, aber per phpMyAdmin schon, kann ich mir so nicht vorstellen.


    Da wir das Ganze aktuell wieder haben, werde ich das gleich nochmals genau so wiedeholen und dokumentieren.


    Zitat


    Ich vermute mal, dass nach dem Starten von GREYHOUND im einen Fall länger gewartet wurde als im anderen Fall. GREYHOUND aktualisiert nach dem Start die Ordnerzahlen nach und nach neu, weil diese sich z.B. durch arbeiten an der Datenbank geändert haben können.


    Das kann ich ausschließen. Ich habe auch beim ersten Mal einige Zeit gewartet und auch mehrfach die Option "Anzahl der Element aktualisieren" ausprobiert.


    Zitat


    Schließen Sie bitte auch aus, dass es sich um das hier Greyhound Client friert ein nach Standby beschriebene Problem handelt.


    Kann ich ebenfalls ausschließen - siehe oben (Anzahl der Elemnte wurde mehrfach aktualisiert - Netzwerk war und ist okay).


    Wie gesagt: ich werde es nochmal nachvollziehen. Gerne kann mir beim nächsten Mal auch jemand dabei zuschauen (Mikogo).

    Lustiger Vorführeffekt: Wir hatten wie gesagt heute schon seit Stunden wieder den Effekt, dass die Zahlen für die Elemente komplett falsch waren (viel zu wenig, z. B. "2" für eine Gruppe, wo knapp 100 Elemente drin lagen etc.).
    Nun wollte ich gerade noch mal das Procedere mit dem Repair via GH-Admin durchführen - und habe zu allererst mal ein "Prüfen" durchgeführt ... - ohne vorher den GH-Server zu stoppen. Und siehe da: Nach dem Prüfen stimmen nun die Zahlen plötzlich wieder! ?( Voodoo???

    Hallo


    ich ziehe den Vorgang nochmal hoch. Gibt es dazu schon was Neues?


    Ich bin mir zu 99% sicher das das Problem mit einer externen mySQL-DB zusammen hängt. Ich konnte Andreas Probleme bei uns hier nie beobachten, obwohl ich den GH ja wahrlich auch nicht gerade mit Samthandschuhen anfasse. Aber seitdem wir vor knapp 3 Wochen auf die externe DB umgestellt haben, stimmen die Zahlen bei uns hier auch nicht mehr.


    Mir scheint es so als würden einfach ein paar Elemente immer mit auf die Filterzahlen draufgerechnet, sowohl bei der absoluten Anzahl der Elemente pro Filter als auch bei den davon gelesenen/ungelesenen. Dabei kann es durchaus sein das die absolute Anzahl stimmt, die Anzahl der ungelesenen aber nicht. Beispiel: Ich sehe (1/3) -> es sind 3 ungelsene Elemente zu sehen.


    Wir erstellen übrigens jede Nacht ein Backup mit den Optionen -optimize und -compress, aber dadurch ändert sich an der Problematik bei uns nix. Den phpMyAdmin haben wir nicht drauf um das damit zu testen, dafür aber QueryWorx falls das helfen sollte.


    Lieben Gruß

    Hallo,


    bei ungelesenen Elementen konnte ich das Problem in verschiedenen Konstellation von Elementen schonmal nachvollziehen. Sobald sich aber etwas an den Elementen ändert, ist es mit der nachvollziehbarkeit dahin. Leider habe ich das auch erst auf unserem Produktivsystem geschafft. Um wirklich eine Lösung herbeizuführen, müsste das ganze auf einem Entwicklersystem mit Debugger nachgestellt werden. Wir sind aber auf jedenfall dran.

    Hi,


    seit der 1053 hab ich auch vermehrt Probleme. Manchmal spingt von einer Sekunde auf die andere die Anzeige um und zeigt mir alle Elemente in allen Ordnern als ungelesen an. In der Listansicht sind aber alle gelesen (unfett). Dieses Phänomen verschwindet dann irgendwann wieder (manchmal nach 5 Min., manchmal nach 2 Stunden). Neustart oder "Anzahl aktualisieren" bringt nichts.


    Aktuell hab ich das Problem, dass in einem Ordner immer eine Mail als ungelesen stehen bleibt. Gestern hab ich das kurz mal wegbekommen durch mehrfaches "als gelesen->als ungelesen"-markieren, aber heute tritts schon wieder auf.

    Hallo Christian,


    das mit der einen stehenbleibenden Mail ist mir auch aufgefallen. Eine Zeit lang hatte ich das gefühl, das in einem bestimmten Filter immer x von y Mails als ungelesen angezeigt wurden (die Filteranzeige, nicht in der Listenansicht). Die Differenz war dabei immer gleich. Irgendwann hat mich der fette Filter so angenervt, dass ich eine Regel "für alle als gelesen markieren" über den Filter drüber gejagt habe. Danach war der Filter nicht mehr fett - leider aber nur für kurze Zeit. :(


    Lieben Gruß

    Hallo GH-Team,


    ich glaube ich hab grade einen Ansatzpunkt fürs Debugging gefunden: Der Fehler scheint nur aufzutreten, wenn ich mehrere Mails markiere und durch F3 auf ungelesen setze.


    Eventuell auch nur dann, wenn ich z.B. 5 Mails markiere, wovon 3 als gelesen markiert sind und 2 nicht. M.E. setzt es dann die 2 ungelesenen auf gelesen und lässt die 3 gelesenen auf gelesen. Allerdings betrachtet GH die 3 gelesenen dann in der Anzahlberechnung scheinbar als "ungelesen"?!


    Kann das sein?

    Just seit gestern haben wir das Problem nun auch mal wieder - aus heiterem Himmel. Bei mir ist nun plötzlich fast alles ungelesen. Ich habe dann - wie gewohnt - mal die DB-Prüfung laufen lassen, was ja in der Vergangenheit immer ohne Befund war - aber kommischerweise dennoch geholfen hatte.


    Heute habe ich aber einen Befund:
    Inkonsistente Datensätze in Tabellenrelation "filters_colors" > "colors": 8
    Inkonsistente Datensätze in Tabellenrelation "filters_workflow" > "rules": 1
    Inkonsistente Datensätze in Tabellenrelation "items" > "topics": 124
    Inkonsistente Datensätze in Tabellenrelation "items_contacts" > "items": 11
    Inkonsistente Datensätze in Tabellenrelation "items" > "items_recurrences": 2
    Inkonsistente Datensätze in Tabellenrelation "items_count" > "topics": 10
    Inkonsistente Datensätze in Tabellenrelation "items_count" > "users": 37
    Inkonsistente Datensätze in Tabellenrelation "items_protocols" > "users": 7
    Inkonsistente Datensätze in Tabellenrelation "items_tappointments" > "items": 3
    Inkonsistente Datensätze in Tabellenrelation "items_tcalls" > "items": 1
    Inkonsistente Datensätze in Tabellenrelation "items_tfaxes" > "items": 27
    Inkonsistente Datensätze in Tabellenrelation "items_tfiles" > "items": 3
    Inkonsistente Datensätze in Tabellenrelation "items_tletters" > "items": 1
    Inkonsistente Datensätze in Tabellenrelation "items_tnotes" > "items": 3
    Inkonsistente Datensätze in Tabellenrelation "items_ttasks" > "items": 2
    Inkonsistente Datensätze in Tabellenrelation "items_users" > "items": 4
    Inkonsistente Datensätze in Tabellenrelation "items_users" > "users": 1
    Inkonsistente Datensätze in Tabellenrelation "rules_categories" > "categories": 4
    Die Referentielle Integrität für 127 Relationen wurde geprüft.


    Was kann hier passiert sein?



    Das Durchführen von "Reparieren" und "Optimieren" via GH-Admin hat übrigens diesmal nix gebracht. :(
    Ich habe dann das Ganze noch mal via phpMyAdmin gemacht - und beim Optimieren bekam ich bei den meisten Tabellen die Meldung "Table is already up to date" - allerdings bei der items_count hat er mir ein "OK" angezeigt. Da wurde also offenbar was optimiert. Selbiges übrigens bei den Tabellen settings und users.


    Leider haben die Operationen via phpMyAdmin diesmal nix gebracht (optimize UND repair). Bei mir ist aktuell fast alles als ungelesen markiert (in den Ordnern - die Items selbst sind korrekt markiert).
    Ist nervig ....

    Hallo,


    das Problem ließ sich mittlerweile übrigens reproduzieren. Ein entsprechender Bug-Fix befindet sich im nächsten GREYHOUND Release. Falls anschließend immer noch Probleme auftreten, kann die Diskussion und Spekulation gerne wieder eröffnet werden. :)


    @Testpilot_Ziethen: Wenn ich das übersetzen soll, wird es ein Roman. Ich denke zusammenfassend kann man einfach sagen, dass GREYHOUND mehr Datenbankprobleme finden kann, als ein externes Tool. :D

    Bei uns taucht es immer noch auf - und zwar immer dann, wenn jemand eine größere Menge von Elementen markiert hat und dann F3 gedrückt hat (als gelesen markieren).


    Aktuell haben wir das Problem wieder und eine Prüfung der Datenbank mittels GH-Admin zeigt:


    Inkonsistente Datensätze in Tabellenrelation "items_count" > "users": 28
    Inkonsistente Datensätze in Tabellenrelation "items_users" > "items": 3


    Build ist übrigens die aktuellste (1079).

    Moin,


    wir haben Build 1095 installiert und das Problem nach wie vor. Zudem ist mir aufgefallen, dass die Statusanzeige am unteren Fensterrand ebenfalls (seit neuestem?) nicht korrekt ist. Diese zählt auf jeden Fall nicht mehr die Elemente der aktuellen Ansicht korrekt. Ich meine das hätte ich aber auch bei der 1070er und der 1053er mal gehabt, bin mir aber nicht sicher.


    Der folgende Screenshot ist in mehrerer Hinsicht unschlüssig:



    • Der Filter "Posteingang" enthält 39 Elemente (1), welche mir auch in der Statusleiste angezeigt wurden (2). Auf dem Screenshot ist allerdings inzwischen der Filter "Posteingang (Kundenservice)" und die Gruppe "Kundenservice" ausgewählt worden. Die Statusanzeige hat sich nicht aktualisiert.
    • Nun zu dem Urpsrungsproblem dieses Beitrags: Schenkt man dem Filter "Posteingang (Kundenservice)" Glauben (dieser zeigt die Inhalte der Gruppe "Kundenservice" inkl. den beiden Untergruppen an), dann müssten sich darin sechs für mich ungelesene Elemente befinden - vier davon in der Gruppe "Kundenservice". Wähle ich diesen Filter aus und schränke die Ansicht auf die Gruppe Kundenservice ein, dann zeigt diese jedoch insgesamt nur vier Elemente (die Voicemails), und keine davon als ungelesen (3).

    Wir verändern die Gelesen-Markierung im Übrigen auch per Regel. Vielleicht taucht das Problem auf weil nicht der aktuelle Benutzer seine Gelesen-Markierung ändert, sondern das System per Regel?


    Lieben Gruß