[gelöst]Umlaute Dataport ASCII ANSI

Hallo zusammen,
bei uns werden grad die Citrix-Server von 2003 auf 2008 umgestellt. Nach der Umstellung liefern die Dataports bei Umlauten nur noch cryptisches Zeug. Soweit mich mein Google-Blick gebracht hat liegt es wohl daran dass Navision immer (7-Bit?)-ASCII ausgibt, das Betriebssystem jetzt allerdings in ANSI arbeitet. So toll ich die NAV-Tool auch finde - ich halte es für eine Zumutung jetzt alle unsere 2000 Dataports anzupassen und dort jedes auszugebendes Feld erst noch zu konvertieren zu - und das sowohl bei Input als auch bei Output.

Ist irgendwem eine andere Lösung bekannt? Betriebssystem wieder auf ASCII einstellen oder eine Einstellung im .NET-Framework ändern oder so etwas ähnlich zentrales? Bitte aber keine Lösung die mir in der Codeunit 1 alle ä nach ae wandelt - diese Idee habe ich schon verworfen.

Wie geht ihr das Problem an? Seid ihr durch die Dataports schon durch?

WoF

Zuletzt geändert von WoF am 18. August 2011 16:33, insgesamt 1-mal geändert.

Hallo,

also NAV benutzt beim einlesen bzw. importiren von Dataports Codepage 850. Das wird sich auch nach der Umstellung nicht geändert haben. Was sich aber u.U. geändert hat, ist welchem Zeichensatz dein Editor arbeitet, mit dem du dir die Datei angesehen hast (Bitte Editor auf OEM-Zeichensatz oder CP850 stellen). Danach sollte der Editor die Umlaute wieder korrekt anzeigen.

Gruß, Fiddi

Hi fiddi,
danke für deine schnelle Antwort. Leider ist es nicht damit getan wenn der Editor die Daten richtig anzeigt - eine externe Anwendung soll die Daten weiterverarbeiten und die hat die Daten bemängelt. (so bin ich überhaupt erst auf das Problem gestoßen.) Natürlich kann ich nun so nach und nach alle Dataports anpassen bei denen die entsprechende Anwendung die Daten bemängelt - nur bin ich der Meinung dass an der Stelle M$ eigentlich eine Lösung anbieten sollte. Wenn morgen mein Chef wieder da ist werde ich diesen befragen - aber ich bin mir fast sicher dass das Problem über unseren Dienstleister an M$ weitergegeben wird. Ich hatte gehofft das es hier nen "Geheimtipp" gibt wie mit sowas umgegangen wird. Prinzipiell finde ich es ja gut das wir endlich multilunual unterwegs sein können - wenn die chinesen was schicken sieht das immer ziemlich lustig aus - trotzdem sollte es dann in Nav bei den Dataports nen Schalter geben wie die die Daten ausgeben - z. B. ein Encoding.

Wof

Es gibt jetzt noch drei Möglichkeiten, die mir auf Anhieb einfallen:
1. Die Daten sind schon in NAV falsch, d.h. ein Name wurde z.B. an anderer Stelle schon falsch eingelesen.
2. In den Dataports sind schon Routinen zur Konvertierung enthalten, die auf Systemspezifika aufbauen (solle eigentlich nicht sein).
3. Die Daten werden mit unterschiedlichen Sprachversionen von NAV verabeitet.-> Der Kollege in Polen erfasst die Daten mit einer polnischen Windows Spracheinstellung, und du versuchst sie mit einer deutschen zu exportieren.

Gruß, Fiddi

Es gibt jetzt noch drei Möglichkeiten, die mir auf Anhieb einfallen:
1. Die Daten sind schon in NAV falsch, d.h. ein Name wurde z.B. an anderer Stelle schon falsch eingelesen.
2. In den Dataports sind schon Routinen zur Konvertierung enthalten, die auf Systemspezifika aufbauen (solle eigentlich nicht sein).
3. Die Daten werden mit unterschiedlichen Sprachversionen von NAV verabeitet.-> Der Kollege in Polen erfasst die Daten mit einer polnischen Windows Spracheinstellung, und du versuchst sie mit einer deutschen zu exportieren.

Gruß, Fiddi

Ich tippe auf Variante 3.

Verschiedene Codepages der Windowsversionen der einzelnen NAV-Clients könnten hier Schuld sein.
Insbesondere die native Datenbank ist hierfür anfällig, da man sie nicht wie die SQL Datenbank komplett dafür sperren kann.

Wenn es so ist, ist die Lösung alle Clients auf die Codepage vom Server zu stellen. Damit würde man das zumindestens zukünftig vermeiden!
Problematisch sind dann allerdings noch die alten "kryptischen" Daten in der Datenbank.

mfg,
winfy

Ich hab den Mittelweg gewählt: Es werden genau die Dataports angepasst die Datenmüll liefern - und ich mach das erst wenn die Fehler tatsächlich auftauchen...

Ist nicht die Lösung, die ich mir vorgestellt habe, aber immerhin verursacht sie ZUNÄCHST nur wenig Aufwand. Was ein Glück das ich sowas nicht entscheiden und dann vertreten muss.

WoF

Ich tippe auf Variante 3.

Verschiedene Codepages der Windowsversionen der einzelnen NAV-Clients könnten hier Schuld sein.
Insbesondere die native Datenbank ist hierfür anfällig, da man sie nicht wie die SQL Datenbank komplett dafür sperren kann.

Wenn es so ist, ist die Lösung alle Clients auf die Codepage vom Server zu stellen. Damit würde man das zumindestens zukünftig vermeiden!
Problematisch sind dann allerdings noch die alten "kryptischen" Daten in der Datenbank.

mfg,
winfy

Hallo Winfy,
was meinst du mit SQL Datenbank komplett dafür sperren ? die Lösung möchte ich gerne wissen wenn es keine Umstände macht.
mfG
Tawfik
Danke