Anfänger - grundlegende Ansätze zum Excel Import

2 Sachen fallen mir auf:
- im Screenshot hast du , als FieldSeperator, in der der Datei aber wohl ;
- beim Ablauf, du schreibst

- die beiden Felder aus der Tabelle eingefügt und meine Textdatei ausgewählt

du hast sie also in der Requestform eingetragen die kommt wenn man den Dataport startet? Dort sind sie falsch, an der Stelle kannst du bei einem Export Filter definieren, zb nur Nr. 100-500.
Wie mikka schon geschrieben hat, die Felder die du importieren willst müssen in die Dataport Fields, also No. und Description, oder wie sonst die beiden Felder in deiner Testtabelle heissen.

2 Sachen fallen mir auf:
- im Screenshot hast du , als FieldSeperator, in der der Datei aber wohl ;

Das hatte ich für die Tests bereits beachtet, danke aber für das aufmerksame lesen.

- beim Ablauf, du schreibst

- die beiden Felder aus der Tabelle eingefügt und meine Textdatei ausgewählt

du hast sie also in der Requestform eingetragen die kommt wenn man den Dataport startet? Dort sind sie falsch, an der Stelle kannst du bei einem Export Filter definieren, zb nur Nr. 100-500.
Wie mikka schon geschrieben hat, die Felder die du importieren willst müssen in die Dataport Fields, also No. und Description, oder wie sonst die beiden Felder in deiner Testtabelle heissen.

Es lag, wie oben bereits geschrieben an den Dataport Fields. Danke aber auch hier nochmal.

Zum Import von txt-Dateien: beim Import von Feldern mit dem Inhalt "Los-für-Los" treten probleme auf, da die Konvertierung nicht stimmt. Nach der Forumsuche und ein wenig googeln kam nun heraus, dass es an der ANSI bzw. ASCII-Coderierung liegen muss. Gibt es externe programme, die eine txt-Datein entsprechend umwandeln können? Ich habe es bereits mit dem Notepad++ (Empfehlung von weiter oben) probiert. Doch auch nach der Konvertierung und erneutem Öffnen steht die txt wieder auf "UTF-8 ohne BOM". Da es sich letztlich nur um 2 txt-Dateien handeln wird, die importiert werden müssen, wollte ich es zunächst darüber probieren bevor ich mich mit Codeunits beschäftige (z.B. damit). Eine kurze Frage zum Verständnis: NAV benutzt die ANSI-Codierung - richtig?

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

Externe Programme kenn ich nicht.
Du kannst das Tool von Timo nutzen oder auch die Codeunit 11501 "GeneralMgt".
Das betreffende Feld entsprechend in den Dataportfields in die Funktion einbauen.

Schau mal hier: Datensatzkonvertierung mit einem Export Dataport

BTW:
Da fällt mir ein (wo wir gerade beim Konvertieren sind):
Es könnte vorkommen das du Felder importierst, die als String im System "landen". Diese müsstes du mit EVALUATE umwandeln.

hast du die Datei nach der Konvertierung in Notepad++ auch gespeichert? Wenn alles richtig ist sollte es wie im Screenshot aussehen:

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

hast du die Datei nach der Konvertierung in Notepad++ auch gespeichert? Wenn alles richtig ist sollte es wie im Screenshot aussehen:

Habe ich gespeichert, sieht dann (solange die Datei offen ist) auch genauso aus, wie auf dem Screenshot. Sobald ich sie aber neu öffne, ist sie wieder auf "UTF-8 ohne BOM".

Navision erwartet ASCII, nicht ANSI. Öffne die Textdateien in Wordpad und speichere die dann als Kopie im MS-DOS-Format. Das versteht Navision meistens, von ausgefallenen Sonderzeichen abgesehen.

Das "Vorverabeiten" der Datei, kannte ich noch nicht
Aber warum nicht wie ich beschrieben habe die Konvertierungsfunktion der Codeunit nutzen?

Ich würde sagen, das spart auf dauer Zeit?!
(Und vermeidet lästige Fehlermeldungen)

Navision erwartet ASCII, nicht ANSI. Öffne die Textdateien in Wordpad und speichere die dann als Kopie im MS-DOS-Format. Das versteht Navision meistens, von ausgefallenen Sonderzeichen abgesehen.

Du hast Recht, so funktioniert es. Danke für den Tipp.

Zwei Fragen sind jedoch noch:

BTW:
Da fällt mir ein (wo wir gerade beim Konvertieren sind):
Es könnte vorkommen das du Felder importierst, die als String im System "landen". Diese müsstes du mit EVALUATE umwandeln.

Wie kann das passieren? Welche Voraussetungen müssen dafür erfüllt sein und welche Auswirkungen kann das haben?

Kann ich in einer bestehenden Tabelle (item 27) zumindest die Länge eines Textfeldes (nach oben hin) ändern, ohne das es mir die ganze DB kaputt macht?
Ich habe gerade feststellen müssen, dass die Beschreibungen für das Feld "Vendor Item No." für 30 Zeichen konzepiert sind. In der Tabelle habe ich jedoch nur 20 zur Verfügung.

BTW:
Da fällt mir ein (wo wir gerade beim Konvertieren sind):
Es könnte vorkommen das du Felder importierst, die als String im System "landen". Diese müsstes du mit EVALUATE umwandeln.

Wie kann das passieren? Welche Voraussetungen müssen dafür erfüllt sein und welche Auswirkungen kann das haben?

Kann ich in einer bestehenden Tabelle (item 27) zumindest die Länge eines Textfeldes (nach oben hin) ändern, ohne das es mir die ganze DB kaputt macht?
Ich habe gerade feststellen müssen, dass die Beschreibungen für das Feld "Vendor Item No." für 30 Zeichen konzepiert sind. In der Tabelle habe ich jedoch nur 20 zur Verfügung.

Entschuldige, ich wollte dich nicht verunsichern. Es sollte nur ein "hint" auf ein neues Problem sein, was evtl. dich erwarten könnte!
Beispiel: Es kann vorkommen, das du den Artikelpreis importieren möchtest und Navision sich strikt weigert (mit einem Error beim Import) dieses zu Importieren, da ein Wert vom Typ Decimal erwartet wird, jedoch Text vorliegt.

Feldlängen ändern
Das ist genauso wie Keys verändern ein sehr sensibles Thema. Auch hier gilt, das die Felder sich im gesamten System wie ein "roter Faden" verteilen.
Wenn du es an einer Stellen ändern wolltes, must du es überall machen.
Entweder:
a. Mit dem Developers Toolkit alle stellen ausfindig machen, und ändern (könnten bei der "Vendor Item No" nicht so viele Setellen sein!)
oder
b. ein zusätzliches Feld in der / den Tabelle(n) anfügen (dieses müsste allerdings überall wo es benötigt wird, mit eimplementiert werden, z.B. auf der EK-Bestellung)