CC ohne Fin.zup möglich???

Hallo zusammen,

ich habe auf einigen Clients ein sehr eigenartiges Phänomen - einige Objekte liefern falsche Werte.
Ein aktuelles Beispiel: Ein Report ermittelt auf Basis von today einen Datensatz aus einer Tabelle - also setfilter <= today und dann findlast

Rufe ich den Report aus dem Menü heraus auf, zeigt er mir falsche Werte an.
Starte ich den Report aus dem Designmodus heraus bzw. speichere ich das Objekt neu, liefert der Bericht die korrekten Werte.

Nachdem ich die ZUP Datei gelöscht habe, funktioniert der Bericht wieder einwandfrei.

Habt Ihr eine Idee wie man das lösen kann bzw. woran das liegt?
Oder gibt es einen Parameter für die finsql.exe um den Client ohne ZUP Datei zu betreiben?

Danke & Gruß
42

Oder gibt es einen Parameter für die finsql.exe um den Client ohne ZUP Datei zu betreiben?

Sowas hier?

Rufe ich den Report aus dem Menü heraus auf, zeigt er mir falsche Werte an.
Starte ich den Report aus dem Designmodus heraus bzw. speichere ich das Objekt neu, liefert der Bericht die korrekten Werte.

Das hört sich nach Hidden- Fields auf der Requestform, oder deren nicht Beachtung an. Ein Report merkt sich nomalerweise Filter und Optionswerte nach der Beeendigung des selben.
Wenn du den Report jetzt aus dem Designer startest oder neu kompiliert speicherst, werden die Daten gelöscht.

Gruß, Fiddi

@elTorito Danke für den Link, aber das hilft mir nicht weiter. Wir nutzen für unsere unterschiedlichen Umgebungen (Produktion, Entwicklung, Test) bereits unterschiedliche ZUP Dateien.

@Fiddi Das hatte ich auch schon geprüft - aber leider Fehlanzeige. Was mich an der Sache stört ist, dass ich das Problem schon einmal auf der Artikelkarte hatte - ich kann ja schlecht alle zwei Wochen alle Objekte öffnen und neu speichern. Bei einzelnen Anwendern kann ich in solchen Fällen natürlich die ZUP Datei löschen (lassen) - aber bei unseren Jobservern u. Diensten wäre es einfach praktischer von vornerein die Anlage der ZUP Datei verhindern zu können.

Gruß
42

Kannst du nicht am Anfang des Reports die Variablen nullen bzw. neu initialisieren?
Dann sollten die errechneten Werte doch stimmen?

1. Es gab mal in einer 2009er Version ein Problem, wenn man über einen Tageswechsel hinweg lief. Hier wurde das Datum nicht mehr richtig erkannt. Mußt du mal googlen, ob das bei euch zutrifft und dann einfach das entsprechende Buildupdate installieren.
2. TODAY wird aus der Systemuhr der jeweiligen Maschine generiert, auf der die Funktion ausgeführt wird. Stimmen eure Systemuhren?

Hallo Horst,

ja die Systemuhren stimmen - ich habe beim googlen jetzt nichts gefunden. Kannst Du mir bitte einen Link zumailen?

Danke

42

Ich hab jetzt auf die Schnelle nur einen Artikel für NAV 2013 gefunden, aber ich bin mir sicher, daß das auch in 2009 ein Problem war. http://support.microsoft.com/kb/2829080/en-us

Aber aufgepaßt, das betrifft nur die Verwendung von WORKDATE über einen Tageswechsel. Du hast ja gesagt, du hättest das auch schon mal auf der Artikelkarte gehabt, was sich für mich wie eine andere Konstellation anhört. Oder habt ihr die Artikelkarte (bzw. den Client) über Nacht offen?

Vielen Dank für den Link, das schaue ich mir mal an.

Tja, unser Problem zeigt sich sporadisch an unterschiedlichen Clients. Und leider auch an solchen die täglich neu gestartet werden.
Nach dem Löschen der fin.zup funktionieren die Objekte (Artikelkarte, div. Reports usw.) wieder problemlos. Das interessante war, dass bei dem letzten Problem das Phänomen an vier unterschiedlichen (und neu gestarteten) Clients nachvollziehen konnten...
Ich kann und will nur bei der Vielzahl unserer Anwender nicht einfach täglich die ZUP Datei löschen.

Daher kam die Idee auf, ob man den Classic Client per Parameter dazu zwingen kann ohne Zup Datei zu arbeiten. Dann kann ich zumindest bei den Clients die rund um die Uhr laufen das Problem umgehen.

Denn früher oder später werden die Anwender die Korrektheit der Daten in Frage stellen.

Laufen auf den Arbeitsplätzen mehrere Clients parallel?

Gruß, Fiddi

Normalerweise nicht - wir haben die Anzahl der möglichen Sitzungen pro User beschränkt. Die User der betroffenen Clients dürfen immer nur eine Sitzung offen haben.
Es können max. noch Clients zu unseren Testsystemen laufen - die haben aber immer eine eigene ZUP Datei.

Ich habe das noch nie gemacht, aber wird denn die zup-datei auch tatsächlich auf den Clients gespeichert oder habt ihr ggf. für Benutzer-Verzeichnisse eine Umleitung auf den Server, so dass die zup auf dem Server liegt? Dann könnte das eine Netz- oder Berechtigungsproblem sein.

Volker

Die ZUP Dateien liegen auf den lokalen Maschinen - wobei es unerheblich war ob es sich um eine VDI oder eine physische Maschine handelte.

Ich verstehe den Zusammenhang mit der zup-Datei immer noch nicht.

Sagen wir mal, ihr habt in dem Report auf der Request Form ein Feld, welches ihr für die Filterung heranzieht. Wenn jetzt SaveValues gesetzt ist, dann speichert NAV das zuletzt gesetzte Filterdatum in der zup-Datei ab und nutzt es beim nächsten Aufruf erneut. Allerdings könnten dann die User diesen Wert auch übersteuern, oder nicht?

Sagen wir mal das Feld ist nicht editierbar oder versteckt auf der Request Form, dann würde natürlich immer der Initialwert genommen werden. Je nachdem wo (also in welchem Trigger) man diesen Initialwert setzt, könnte dieser von dem Wert in der zup-Datei wieder überschrieben werden. Voraussetzung auch hier ist, daß SaveValues gesetzt ist. Nur dann hätten die User das immer nach dem erstmaligen Benutzen. Oder anders formuliert, nachdem du die zup-Datei des jeweiligen Users gelöscht hast, funktioniert es für diesen User genau einmal.

Es kann also eigentlich nicht sein, daß es für einen User mal geht und mal nicht. Es sei denn, er wechselt zwischendurch an einen anderen Rechner (andere zup-Datei) oder er hat zwei Clients offen und läßt die zup-Datei von dem Client schreiben, von dem er nicht den Report ausgeführt hat. Im zweiten Fall würde es nämlich dann keinen SaveValues-Wert in der zup-Datei geben und der Initialwert würde wieder zum Tragen kommen.

Für mich heißt das, wenn es so ist, wie im zweiten Fall beschrieben, dann solltest du den Initialwert im Report an einer anderen Stelle setzen und nicht mit der zup-Datei irgendwas versuchen. Evtl. kann hier auch das Abschalten von SaveValues eine Lösung sein. Kommt darauf an, was dort genau gemacht werden soll in dem Report.

Noch eine andere Vermutung: Kann es sein, daß die User den Record im Zugriff haben, aus dem nachher mit <= TODAY und FINDLAST ein Datensatz entnommen wird? D.h. sehen die User den als Data Item? Wenn ja, wird hier möglichweise ein anderer Schlüssel bzw. eine andere Sortierreihenfolge gewählt?