Beiträge von Ralf25

    Ich schrieb ja nur, dass mir weiterhin bei der Anzeige ein bis jetzt für mich etwas unlogisches Verhalten aufgefallen ist. Vermutlich wird es dafür einen recht einfachen - im Verhalten von GoPal begründeten - Grund geben. Nur da mir "fehlende Favs." bisher in der Praxis noch nie aufgefallen waren und es auch bei der Nutzung des GoMan (noch) nicht zu einem "Problem" gekommen ist, ist das keine Sache, um die ich mich in der Endphase des Einsatzes von GoPal v6 kümmern müsste. ;)


    Aber vielen Dank für Dein Angebot! :023:

    - Bingo, es geht hier um die Favs. von GoPal v6! ;) Aber wenn sich eine allg. Diskussion ergibt, verallgemeinere ich das Thema, kein Problem


    - die ID selber spielt keine Rolle (wichtig ist bzw. wäre nur eine korrekte interne Verknüpfung => join_id), es ist nur ein Indiz auf sehr stark genutzte Fav.-einträge (Löschen/Neu anlegen); BTW: er GoMan würde alles neu durchnummerieren beim Speichern


    - wichtig ist hier nur der Typ


    - die von mikee erwähnten 30 waren IMO nur auf die Anzeige bezogen, tatsächlich können sich in der *.db wesentlich mehr Einträge befinden (zusätzl. "letzte Orte"); in der DB hatte ich schon > 450 Einträge, die kann das ab :top_001:

    Ich vermute, die Problemfälle sind alles Altdaten und die Vorversionen waren hier jeweils "unkritischer" in der Plausibilisierung der einzelnen Angaben, warum auch immer. :dontknow: Vlt. fällt Dir bei weiteren Tests ein einhetliches Muster (Regel) auf, was sich dann evtl. auch auf die v7 auswirken würde. Sofern es dort zum Problem kommt. :denk_002:


    Jetzt im Nachhinein vermute ich fast, dass sich eben dort die erwähnten fehlenden Pos.-angaben negativ bemerkbar gemacht hatten.

    Ich hab bei mir unter v6 jetzt auch 2x zwei Einträge gefunden (Typ 1 & 2), die nicht angezeigt werden und wo 'cityTransliteration' gefüllt ist. Dann aber auch 1 Eintrag, der doppelt vorhanden war und sich nur im Typ unterschied (1 & 2), aber trotzdem unter "Letzte Orte" (Typ = 2) angezeigt wird. Allerdings ist dort dann 'suburb' gefüllt. :017:


    Hab jetzt eher nur grob und oberflächlich gesucht, aber es ist schon echt komisch soweit das bisherige Ergebnis! :icon_mrgreen:


    Ob sich hier eine Regel ableiten lässt, kann ich nicht sagen. Wie auch nicht im Nachhinein, wie dies zustande gekommen sein könnte. Weil mir eben bewusst kein Eintrag fehlt bzw. ich ihn vorher vermisst gehabt hätte. Aber ich spiele natürlich auch oft mit der DB und speichere Sicherungen zurück. Und meine letzten Ziele bereinige ich sehr oft und die Favs. ändern sich eher wenig. :denk_002:

    Ach sorry, genau umgekehrt war's gemeint. Eben, so wie man's sieht. ;) Du siehst doch selber mögliche Unterschiede in den Zeilen, geh's doch mal stückweise durch. Bisher wurde dieses Verhalten noch von keinem festgestellt. :dontknow:


    - - - - -automatisch zusammengefasst - - - - -


    countryCode hab ich bei dem Eintrag in Zeile 719 schon mal auf 0 (Null) gesetzt - hat nix gebracht und bei anderen Einträgen bei denen auch ein countryCode mit drin steht, die werden angezeigt.


    Wie gesagt, geh mal in die Map und lege etwa in der Umgebung einen neuen Fav. an.

    Nun ja, da seh ich doch schon ein paar Unterschiede, mit denen man "spielen" könnte:
    - countryCode (ich kenne nur -1 und 45 >= x <= 49); mit -1 könnte man es mal probieren
    - cityTransliteration ist scheinbar egal, aber streetTransliteration könnte mal testweise gelöscht werden



    EDIT: ansonsten auch mal einen neu anlegen, der bisher nicht auftauchte, und dann vergleichen

    Servus & :welcome: hier im Forum!


    Schön, dass es jetzt doch noch geklappt hat mit dem Posten! :top_001:


    mein Navi zeigt nur "gewisse" DB Einträge an, andere ganz einfach nicht. Mit TKSQLite sehe ich alle meine gespeicherten Favoriten - nur das Navi zeigt sie nicht an.


    Mhm, wenn die Fav.-DB generell an der falschen Stelle steht, dürften ja überhaupt keine Favs. gefunden werden.


    Meine Vermutung: Kann es sein, dass bei diesen Einträgen die Angaben zu Lat./Long. fehlen (IMO gab's da zur v6.0 mal eine Umstellung) oder sich sonstwie die Einträge unterscheiden? :dontknow:

    Es sei denn, Du meinst mit "aus eigener Kraft" das Torverhältnis in einem Spiel um 10 Tore zu verbessern


    Stimmt, bei Szenario 6 macht sich dann das schlechte Torverhältnis des HSV bemerkbar. ;( Und ein 11:0 gg. S04 ist dann doch eher unwahrscheinlich. ^^ Tja, dann müssen wir aus HSV-Sicht wohl die Daumen drücken, dass zumindest das Spiel H96 : SCF nicht unentschieden ausgeht.
    Wobei man generell nur darauf hoffen kann, dass die Spiele und damit letztlich der Abstieg nicht wesentlich durch Fehlentscheidungen beeinflusst oder gar entschieden werden.

    Trotz allem und aufgrund der besonderen Konstellation der Paarungen am letzten Spieltag (der 15. gg. den 14. und der 18. gg. den 16.) darf sich der HSV als 17. glücklich schätzen, es immer noch aus eigener Kraft schaffen zu können. :tup