Abspeichern gefilterter Ansichten nicht möglich

Hallo,
eine Mitarbeiterin eines unserer Kunden hat das folgende Problem: Wenn Sie mit einem bestimmten Rollencenter startet und dort versucht, eine gefilterte Ansicht zu speichern, stürzt der Client mit der Meldung, dass die Verbindung zum Server getrennt wurde, ab.
Andere Mitarbeiter können im selben Rollencenter gefilterte Ansichten speichern.
Die .zup-Datei habe ich umbenannt.
Meldet sich ein anderer Mitarbeiter am Rechner der besagten Mitarbeiterin an, funktioniert es auch.
Jemand eine Idee für eine Lösung? Gibt es ein Limit für die Anzahl der möglichen Benutzeranpassungen? Die Mitarbeiterin hat recht viele.

MfG

ist es egal, welche Ansicht sie abspeichert?
Weiterhin wäre die Frage, wieviele Benutzeranpassungen die Dame hat - dann wäre die Grenze geklärt

264 Anpassungen. Es ist egal, welche Ansicht sie abspeichert, sie kann diese nicht einmal löschen.
Ich habe dann einmal mit meinem Benutzer über Benutzeranpassungen löschen aufs geratewohl einige Einträge entfernt, kein Erfolg.

Hallo,

hast du wirklich die .ZUP- Datei umbenannt, oder doch die Personalisationstore.xml. letztere funktioniert nur unter 2017-RTC.

Gruß Fiddi

Die, bzw. eine .zup-Datei. Die Kundin hat noch Nav 2009 auf dem gleichen Rechner im Einsatz.
Ich habe mich inzwischen mal kundig gemacht, wann die .zup-Datei verwendet wird und wann die Personalizationstore.xml (hätte ich mal früher tun sollen ).
So, wie es aussieht, ist die Personalizationstore.xml noch ein aussichtsreicher Kandidat zum Löschen bzw. Umbenennen. Jetzt ist allerdings die Frage: Kann man die Einträge aus dieser retten? Vermutlich nicht. Das ist allerdings suboptimal, die Mitarbeiterin will unbedingt ihre alten Einträge behalten.

ist es egal, welche Ansicht sie abspeichert?
Weiterhin wäre die Frage, wieviele Benutzeranpassungen die Dame hat - dann wäre die Grenze geklärt

Ist jeder Eintrag in der xml-Datei eine Anpassung? Bei mir sind es 1.333 Einträge. Aber da scheinen sich einige zu wiederholen.

Cheers,

Hallo,

die Personalisationstore.XML enthält Einträge pro Menüpunkt und anscheinend auch pro Bildschirmauflösung (Terminalserver, Homeoffice).
Daher sieht es nur so aus als ob sich Einträge wiederholen.

Mit etwas Aufwand kann man die Datei mit einem Texteditor bearbeiten und versuchen den fehlerhaften Eintrag zu löschen.

Gruß Fiddi

Etwas Aufwand ist gut, ich habe mir mal eine beliebige Personalizationstore bei uns angesehen, wenn mich nicht alles täuscht, ist die verschlüsselt, wie ich da einen Fehler finden soll, erschließt sich mir gerade nicht.

Hat die Kollegin noch andere Probleme in NAV? Handelt es sich um eine lokale NAV Installation oder Terminalserver?
Evtl. fehlen Addins oder klingt komisch: Die Uhrzeit des PCs weicht zu sehr von der Uhrzeit des NAV Tier Servers ab.

Hallo,

die Felder sind nicht verschlüsselt, nur Base64-Encoded. Solltest du mit einem Notpad++ + Erweiterung "entschlüsseln" können.

Gruß Fiddi

@vandyke: lokaler Client. Wenn sich ein Kollege an Ihrem Client anmeldet funktioniert alles. Sie hat keine anderen Probleme.

Benenn doch die Datei mal um, dann siehst du ja ob es daran liegt.

Die Personalizationstore habe ich umbenannt, das Abspeichern der gefilterten Ansichten führt immer noch zum Absturz des Client
Ich muss mich allerdings an einer Stelle korrigieren, anscheinend benutzt die Mitarbeiterin tatsächlich einen Terminalclient. Sie hat die Probleme auch, wenn sie sich an einem anderen Rechner anmeldet

Hallo,

da erinnere ich mich an ein ähnliches Thema mit 2015. Da half ein technisches Upgrade.

Gruß Fiddi

Ich muss mich allerdings an einer Stelle korrigieren, anscheinend benutzt die Mitarbeiterin tatsächlich einen Terminalclient. Sie hat die Probleme auch, wenn sie sich an einem anderen Rechner anmeldet

Na wie denn nun? Der NAV Client ist auf den lokalen PCs installiert und sie öffnet das lokal installierte NAV oder sie meldet sich per Remote Desktop Verbindung auf einem Terminalserver an und öffnet ein dort auf dem Terminalserver installierten NAV Client?

Aaaalso, die Benutzerin hat eine "kleine Kiste", einen Bildschirm und eine Tastatur, also Terminalclient. Die genauen Daten kann ich leider nicht mitteilen, konnte ich auf die Schnelle nicht ermitteln, als ich bei der Dame via TeamViewer auf dem Ding war. Das müsste alles der Sysadmin wissen, den erreiche ich z.Zt. aber nicht.
Allerdings habe ich mir das Ereignisprotokoll des Rechners einmal angesehen, auf dem die Serviceschicht installiert ist, die gab zeitglich mit dem Absturz die folgende Meldung aus:

Type: System.Runtime.Serialization.SerializationException Message: Die maximale Anzahl der Elemente in einem Objektgraph, die serialisiert bzw. deserialisiert werden können, beträgt "512000". Ändern Sie den Objektgraph oder erhöhen Sie das MaxItemsInObjectGraph-Kontingent…

Ich habe dann ein wenig geforscht und herausgefunden, dass es da den Parameter Max Items In Object Graph in der Einrichtung des Dienstes gibt. Was der nun allerdings genau macht, hat sich mir noch nicht recht erschlossen, insofern wollte ich da auch nicht nach Gutdünken dran rumfummeln.

https://krishankantsinghal.medium.com/serialization-and-deserialization-5046c958c317
https://aloiskraus.wordpress.com/2017/04/23/the-definitive-serialization-performance-guide/

verdopple mal die Anzahl - vielleicht auf nem zweiten NST und lass die Userin mal da drauf - mal sehen was passiert :)

Das mit dem zweiten Dienst ist eine gute Idee, danke für den Tipp.

Treffer, versenkt! Ich habe einen zweiten Dienst erstellt, den Parameter mit dem doppelten Wert versehen, und siehe da, es funktionierte (danke @sweikelt). Jetzt wäre es allerdings mal interessant zu wissen, was es für Folgen zeitigt, wenn man diesen Wert langfristig für alle User erhöht. Nicht, dass es die Datenbank damit in die Knie zwingt.

Nicht, dass es die Datenbank damit in die Knie zwingt.

die DB wird davon nicht betroffen sein - ich denke der Dienst könnte bisl mehr RAM verbrauchen - aber das ist nur eine Vermutung

Bis jetzt funktioniert es, ich markiere den Beitrag daher als gelöst. Allerdings würde mich schon interessieren, wodurch der Fehler genau hervorgerufen wurde, an den Benutzereinstellungen hat es ja nun nicht gelegen, zumindest nicht allein. Noch irgendwer einen Tipp in dieser Hinsicht?