Beim erzeugen einer Datei erscheint immer ein Filedialog

Guten Morgen zusammen,

wenn ich ganz einfach eine Datei erzeugen möchte, z.B.:
File -> file
file.CREATE('d:\test.txt');
file.CLOSE;

dann öffnet sich beim "file.Create" immer noch ein Filedialog, wo ich Pfad und Dateinamen ändern könnte.

Kann man diesen FileDialog unterdrücken, da bei uns etwas automatisiert läuft und wir diesen nicht brauchen, ganz im Gegenteil?
Von der 2009er Version kenne ich dieses Verhalten auch nicht so.

Vielen Dank im Voraus und allen einen schönen Tag,
HerbertGross

Bei Wechsel auf 3-Tier hat sich auch das file-mgt/handling geändert. Dazu gips auch eine Mgt-Codeunit. Sie da mal nach uns nutz die. d:\xyz ist nicht immer da wo Du es erwartest

Danke erstmal, supi, ich gucke es mir mal an.
HerbertGross

Hallo Herbert,

wie Markus schon geschrieben hat, gibt es dazu die Codeunit 419 "File Management".
Für den Umstieg von NAV2009 (vermutlich Classic-Version) auf NAV2018 würde ich dir empfehlen, dass in deinem Programmcode zuerst eine temporäre Datei auf dem NAV-Server erstellst (Funktion "ServerTempFile") und dann in deiner Verarbeitung in diese Datei schreibst.
Am Ende der Verarbeitung kannst du die temporäre Datei dann mit der Funktion "DownloadTempFile" oder der Funktion "DownloadToFile" (ein Beispiel findest du im Report 91) auf dem Client speichern.

Guten Morgen,

ja, das ist die Classic-Version. Wir versuchen das mal.
Danke für die hilfreichen Antworten.

HerbertGross

Hier mal ein konkretes Beispiel.

User Story: Gegeben sei ein Zahlungsjournal (T81) aus dem heraus ein XMLPort ein File für die Bank (z.B. ISO20022, SEPA) erstellen soll.
Dabei möchte ich den Filenamen fix vorgeben. Es soll also kein "Save As" Dialog gestartet werden.

Code:

VAR
TempBlob : Record 99008535;
FileManagement : Codeunit 419;
OutputClientFile : Text;
OutStr@1000 : OutStream;
NVInStream : InStream;
XMLPortID : Integer;

BEGIN
  XMLPort := 50000;
   TempBlob.INIT;
   TempBlob.Blob.CREATEOUTSTREAM(OutStr);

  // Hier wird nun der XMLPort aufgerufen. GenJnlLine (T81) ist gefiltert auf die Datensätze, die generiert werden sollen.
  // Output ist TempBlob aus dem wir dann einen Instream erzeugen:
   XMLPORT.EXPORT(XMLPortID,OutStr,GenJnlLine);
  TempBlob.Blob.CREATEINSTREAM(NVInStream);

Nun geht es "nur" noch darum, diesen NVInStream als Datei z.B. als "C:\Temp\blabla.xml" zu speichern.
Theoretisch müsste das wie folgt funktionieren. Aber aufgepasst! Die rote Zeile funktioniert nicht wie gewünscht!
IF DOWNLOADFROMSTREAM(NVInStream,'Export', 'C:\Temp\','','Blabla.xml') THEN ....

Die Crux liegt beim dritten Parameter, der den Ziel-Pfad enthält: Wenn dort ein echter Pfad drinsteht (wie bei mir "C:\Temp\"), dann erscheint der unerwünschte "Save As" dialog.
Den Dialog können wir nur unterdrücken, wenn wir als Ziel-Pfac "<TEMP>" oder sauberer den Magicpath aus dem Filemanagement verwenden.
Das ist allerdings nur die halbe Miete, denn nun liegt meine Datei im Temp-Verzeichnis. und muss noch verschoben werden.

Also:

Code:

          OutputClientFile := 'Blabla.xml';
          IF DOWNLOADFROMSTREAM(NVInStream,'Export', FileManagement.Magicpath,'',OutputClientFile) THEN BEGIN
            FileManagement.MoveFile(OutputClientFile, 'C:\Temp\Blabla.xml');
          END;

Zu beachten ist auch noch, dass die Funktion DOWNLOADFROMSTREAM meine Variable "OutputClientFile" mit dem effektiven Namen überschreibt.
Somit wird aus 'Blabla.xml' ein langes "C:\User\<schlagmichtot>\Temp\Blabla.xml'

ein langes "C:\User\<schlagmichtot>\

Code:

FileManagement.MoveFile(OutputClientFile, 'C:\Temp\Blabla.xml');

Mit BC 14 klappt das Verlegen von der temporären Clientdatei mit MoveFile zumindest bei meiner aktuellen Client-Server-Konstellation (Kundensystem) merkwürdigerweise nicht.

Code:

FileMgt.MoveFile(OutputClientFile,ParentPath + LocalFileName);

erzeugt weder eine Fehlermeldung noch eine Datei (bzw. nicht da, wo sie hin soll )

Code:

FileMgt.MoveAndRenameClientFile(OutputClientFile,LocalFileName,ParentPath);

generiert die Zieldatei dagegen problemlos im gewünschten Verzeichnis.

Hallo,

Mit BC 14 klappt das Verlegen von der temporären Clientdatei mit MoveFile zumindest bei meiner aktuellen Client-Server-Konstellation (Kundensystem) merkwürdigerweise nicht.

Lass mich mal vermuten: Du arbeitest lokal mit einem System bei dem Server und Client auf einem Rechner laufen, beim Kunden sind das getrennte Rechner?

Gruß Fiddi

Lokal mache ich gar nichts, ich arbeite via Citrix Virtual Desktop beim Kunden, damit komme ich auf den ersten Server, von da geht es mit Remote Desktop auf den nächsten virtuellen Server mit dem BC 14 System, welches die fertigen Dateien auf einem Netzlaufwerk ablegen soll. Dort habe ich nur ab einer bestimmten Unterverzeichnisebene Schreibberechtigung, auf dem BC 14 Server bin ich lokaler Admin und nutze den dort installierten Windowsclient zur Erzeugung.

Ich habe eher einen fehlenden Backslash hinten beim ParentPath im Verdacht, das Automation FileSystemObject mit GetParentFolderName löse ich an vielen Stellen durch GetDirectoryName aus Codeunit 419 ab.
Ich prüfe das nächste Woche noch mal genauer, bin morgen nicht im Büro. Für heute hat es auch erstmal genug Fehlermeldungen gehagelt .

Hallo,

Die Move- Funktion (suboptimaler Name) ist eine Client- Funktion. D.h. Sie wird auf dem Client ausgeführt. Wenn der Client EDIT:also nicht exakt die gleiche Laufwerksstruktur und Berechtigungen wie der Server hat Der Client nicht auf die exakt gleiche Laufwerksstruktur und Berechtigungen wie der Server zugreift, hast du ein Problem.

Aber wenn du sicher gehen willst, das etwas funktioniert, würde ich mir immer genau anschauen wo welche Funktion ausgeführt wird. Wenn die Datei vom Server erzeugt wird, kann er die sofern er unter einem Domänen- Account läuft direkt in ein Verzeichnis schreiben auf das der Account zugriff hat.
Hat er das nicht, ist der Weg immer ServerTemp-Datei erzeugen, Download auf den Client, Client verschiebt die Datei, wenn nötig.
Lässt du den Schritt mit dem Download weg, funktioniert das ganze nur, wenn Client auf dem Rechner des Servicetiers läuft, dann hat Client u.U. Zugriff auf den Pfad des Serverdateinamens und der Move funktioniert auch mit dem Client.

Gruß Fiddi

Danke für die Hinweise, Fiddi, ich werde wohl noch viel "Spaß" mit diesem Netzwerk haben .

Ich habe eher einen fehlenden Backslash hinten beim ParentPath im Verdacht, das Automation FileSystemObject mit GetParentFolderName löse ich an vielen Stellen durch GetDirectoryName aus Codeunit 419 ab.

Die Vermutung war schon richtig, böse Falle: GetParentFolderName und GetDirectoryName verhalten sich gleich oder unterschiedlich, je nachdem, ob im Pfad hinten ein Backslash steht oder nicht. Beim Kundensystem sind die Pfade in einem Tabellenfeld hinterlegt (inkl. Backslash, meistens jedenfalls ), und der Name der zu erzeugenden Datei in einem anderen Feld.

COM: GetParentFolderName mit C:\MyDir\MySubDir\ oder C:\MyDir\MySubDir liefert jeweils C:\MyDir
.NET: GetDirectoryName mit C:\MyDir\MySubDir\ liefert dagegen C:\MyDir\MySubDir, nur C:\MyDir\MySubDir liefert C:\MyDir

Nachtrag: MoveFile hat in diesem Fall also die Zieldatei mit einem aus Order- und Dateinamen zusammengesetzten neuen falschen Dateinamen eine Ebene höher als im Zielordner abgelegt.

Hallo,
ich meine Timo hat mal ein schönes Code- Schnipselchen hier veröffentlicht.

Code:

FileNamePath := DELCHR(DestPath,'>','\')+'\'+filename;

Gruß Fiddi