TEMPORARYPATH: kein Temp-Pfad des Users mehr?

21. April 2020 16:04

Hallo zusammen,

ich bin gerade etwas verwundert, dass der TEMPORARYPATH den Pfad in diesem Format ausgibt:
Anmerkung 2020-04-21 160205.jpg

War es nicht Mal so, dass dieser Befehl dem temporären Pfad so ausgibt:
C:\Users\[Benutzername]\AppData\Local\Temp

Danke.

Gruß
Alexander
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Re: TEMPORARYPATH: kein Temp-Pfad des Users mehr?

21. April 2020 17:49

ich lehn mich jetzt mal aus dem Fenster:
--> das war bis 2009 CC so
https://docs.microsoft.com/en-us/dynamics-nav/temporarypath-function

If this function is called from an application that is running on a Dynamics NAV Application Server, it returns the path of the directory where the Dynamics NAV Application Server is installed.

Re: TEMPORARYPATH: kein Temp-Pfad des Users mehr?

22. April 2020 07:13

Ja, die Dokumentation habe ich auch gesehen.
Trotzdem kann ich mir gerade nicht erklären, warum einige Dinge seit dem Wochenende anders laufen als vorher.

Durchgeführt haben wir folgendes:
1. Einen Windows Server 2012 durch einen Windows Server 2012 ersetzt
2. Das CU54 vom NAV2016 installiert

Wenn ich das Ganze richtig verstehe, müssten auf dem alten Server, der seit dem Wochenende nicht mehr läuft doch einige Verzeichnisse im Ordner
C:\ProgramData\Microsoft\Microsoft Dynamics NAV\90\Server\MicrosoftDynamicsNavServer$[Dienstname]\users
vorhanden sein, oder?
Da ist aber kein Ordner.

Unser Problem ist gerade, dass seit der Umstellung einige Dokumente nicht mehr korrekt erstellt werden können.

Hat noch jemand eine Idee?

Danke.

Re: TEMPORARYPATH: kein Temp-Pfad des Users mehr?

22. April 2020 09:43

Hallo,

du solltest die Variable TEMPORARAYPATH nicht verwenden, sondern Funktionen die Codeunit 419 File Management bereitstellt.

TEMPORARYPATH wirkt im allgemeinen auf den Servicetier. D.h. nur die Verzeichnisse, für die der Benutzer Berechtigungen hat, unter dem der Servicetier läuft können benutzt werden. (der Servicetierbenutzer bzw. dessen lokale Berechtigungen auf dem Server könnten übrigens das Problem sein. Der sollte lokaler Administrator sein)

Im CC war TEMPORARYPATH immer auf dem Client. das ist mit dem RTC nicht mehr so.

Im RTC musst du Dateien auf dem Servicetier temporär erstellen, und dann auf den Client herunter laden, wenn du sie dort benötigst. (oder der Servicetier schreibt die Datei auf eine gemeinsam genutzte Netzwerkfreigabe)

Gruß Fiddi

Re: TEMPORARYPATH: kein Temp-Pfad des Users mehr?

22. April 2020 09:47

naja - vielleicht war es ja ein Bug im vorhergehendem CU.
ist das eine Standard-Funktionalität, die Ihr verwendet (ich denke nicht).
Dir wird nichts anderes übrig bleiben, als den Code zu korrigieren.
Kleiner Tipp: Nutzt die CU 419 für das erstellen von Dateien....

zannaleer hat geschrieben:Unser Problem ist gerade, dass seit der Umstellung einige Dokumente nicht mehr korrekt erstellt werden können.

wurde einfach so das CU-Update durchgeführt - ohne Test? ....also wenn ihr keine Anpassungen habt, dann "kein Problem", aber wenn ihr welche habt....dann solltet ihr vorher einen Test durchführen

Re: TEMPORARYPATH: kein Temp-Pfad des Users mehr?

22. April 2020 10:02

Fiddi hat geschrieben:Im RTC musst du Dateien auf dem Servicetier temporär erstellen

Bei den Temppfaden auf dem Server, die ich in der Praxis verfolgen musste, waren bislang da auch noch numerische Unterordner dabei, also z.B. …\TEMP\12345.
Dort lag dann die Datei, die ggf. zum Client kopiert wurde.

Re: TEMPORARYPATH: kein Temp-Pfad des Users mehr?

22. April 2020 10:13

Die Nummer im Pfad dürfte die Prozess-ID des jeweiligen Servicerier- Prozesses sein.

Gruß Fiddi

Re: TEMPORARYPATH: kein Temp-Pfad des Users mehr?

22. April 2020 17:26

So ich bin einen Schritt weiter.
Das mit den Tamp-Pfaden war anscheinend tatsächlich schon immer so in NAV2016.
Mein Problem wird wohl daher verursacht, dass beim Zusammenspiel von Microsoft Office mit dem Windows Server 2016 etwas anders läuft als beim Windows Server 2012.

Auf einem anderen Windows Server 2016 tritt nämlich der gleiche Fehler auf.

Gruß
Alexander