[Gelöst] Problem mit Sonderzeichen unter Win 7 + NAV 2009

Hallo zusammen,

ich habe das Problem, dass unsere User sehr gerne Werte aus Excelzellen nach NAV kopieren. Das Problem dabei ist, dass der NAV Export diese Zeichen als CRLF interpretiert und dadurch die Datein wunderbar zerschießt.
Unter Win XP war das weiter kein Problem, da man in Text-/Codefeldern nach diesen zwei Quadraten suchen und diese dann ersetzen konnte. Unter Win7 funktioniert aber a) unsere Korrekturfunktion nicht mehr - die Sonderzeichen findet Nav zwar noch, schafft es aber nicht diese zu löschen. Warum auch immer.
Und b) zeigt Nav diese Sonderzeichen gar nicht mehr an, da das am Textende ist fällt einem das einfügte "Leerzeichen" gar nicht mehr auf.

Hat jemand von Euch einen Lösungsansatz oder das Problem auf andere Art und Weise behoben?

Gruß
42

Zuletzt geändert von 42 am 16. März 2010 14:02, insgesamt 1-mal geändert.

leider keine Lösung, nur das gleiche Problem (mit 4.0SP3 Client unter Win7) :(

Das hat mich direkt interessiert, weil mich diese beiden Zeichen aus Excel auch schon seit Langem ärgern.
Interessanterweise hat ein Versuch mit einem kleinen Stück Code:

Code:

LocRecCL.RESET;
LocRecCL.SETRANGE("Table Name", LocRecCL."Table Name"::Item);
LocRecCL.SETRANGE("No.", ....
LocRecCL.SETRANGE("Line No.", ....
IF LocRecCL.FINDFIRST THEN
  FOR i := 1 TO STRLEN(LocRecCL.Comment) DO BEGIN
    EVALUATE(Character, COPYSTR(LocRecCL.Comment, i, 1));
    IntChar := Character;
    ResultString += FORMAT(IntChar) +';';
  END;

  MESSAGE('Ascii-Values: %1', ResultString);

auch nur ergeben, dass es sich um CHR(10) und CHR(10) handelt ... Der Text
KATEGORIEN & INDIZES PFLEGEN
ergab:

75;65;84;69;71;79;82;73;69;78;32;38;32;73;78;68;73;90;69;83;32;80;70;76;69;71;69;78;13;10;

Pidi

das Problem ist ja auch weniger jetzt genau diesen Fall herauszufiltern, sondern dass Win7 generell diese Kästchen nichtmehr anzeigt. Ich bin mir sicher dass es noch mehr Möglichkeiten ausser Excel gibt irgendwelche Sonderzeichen in die Zwischenablage zu bekommen (zb Webseiten).
Es wäre halt gut wenn es eine Möglichkeit gäbe diese Kästchen wieder anzeigen zu lassen. Danach kann man immer noch nach einer "Komfortlösung" für bestimmte Fälle und Felder schaun ...

Da kann ich nur 100% zustimmen - das die Kästchen nicht mehr zu sehen sind, setzt dem
Ganzen noch einen oben drauf, weil jetzt keiner mehr direkt peilt, was los ist.

Das ist überigens anscheinend ein Windows 7 Problem, denn das taucht beim 5.1er Client auch auf.

Pidi

Hallo 42,

kurze Fragen a) welche Daten werden von Benutzern wo in NAV einzfügen sein? b) warum? und c) warum ständig?

Mein Vorschlag wäre die Nutzung der Excel Datenmigration unter
(Verwaltung | Anwendung Einrichtung | Unternehmen Einrichtung | Datenmigration).
Einmalig die Exceltabelle erzeugen, dem Benutzer zur Verfügung stellen, von diesem überarbeiten lasse und anschließend per Knopfdruck importieren.

Gruß, Grolli

@grolli,

es kommt häufiger vor das Daten aus anderen Datenquellen in NAV eingefügt werden sollen. Das können einzelne Werte sein (ein Excel-Kalkulations- Blatt), der Name eines Lieferanten aus einer Exceltabelle,... Es gibt viele Gründe, warum man einzelne Felder in NAV einfügen möchte, dafür kann man keine Datenmigration einsetzen.

Daher kann ich den anderen nur zustimmen. Das Verhalten ist schon etwas merkwürdig, zumal man als Anwender nicht mehr nachvollziehen kann.

Das Problem ist aber nicht unbedingt ein direktes Windows 7 Problem, sondern eine Sache des eingesetzten System- Fonts. Es gibt/gab in Windows Fonts, die bei nicht darstellbaren Sonderzeichen ein kleines Kästchen ausgeben. Der Standard- Font unter den alten Systemen scheint das getan zu haben. Unter Windows 7 scheint jetzt ein anderer System-Font verwendet zu werden oder der System- Font wurde geändert, sodass er nur noch eine Leerstelle ausgibt. Wenn man jetzt also einen anderen Systemfont wählt, oder den Systemfont für CR und LF wieder ändert, sollte das ganze wieder funktionieren.

Gruß, Fiddi

ich habe auch schon in die Richtung Systemfont gesucht, aber keinen Weg gefunden diesen zu ändern. Wenn da jemand einen Tip hat könnte das die Lösung sein.
Ein Import kommt nicht in Frage, dafür sind die Quellen viel zu verschieden. zB Artikel anlegen und dafür einen Beschreibungstext von der Webseite des Lieferanten kopieren, oder Text aus einer Mail, oder 1-2 Werte aus einer Excel Tabelle etc. Da muss Copy + Paste einfach funktionieren ...

Hallo 42,

Unter Win XP war das weiter kein Problem, da man in Text-/Codefeldern nach diesen zwei Quadraten suchen und diese dann ersetzen konnte. Unter Win7 funktioniert aber a) unsere Korrekturfunktion nicht mehr - die Sonderzeichen findet Nav zwar noch, schafft es aber nicht diese zu löschen. Warum auch immer.

Auf welche Weise funktioniert(e) denn eure Korrekturfunktion? Was geht daran jetzt nicht mehr?
Du schreibst, das die Sonderzeichen erkannt werden. Möglicherweise kannst du deine Korrekturfunktion umschreiben.

Wenn das Löschen der speziellen Zeichen nicht funktioniert, vielleicht gehts ja dann so (nicht getestet ...):

Code:

NormalizeString(S : Text[1024]) : Text[1024]
BEGIN
  for i := 1 to strlen(S) do
    IF NOT (S[i] in [10,13]) THEN
      Result += copystr(S,i,1);

  exit(Result);
END;


Gruß Torsten

Schau dir doch mal folgenden Link an.

Evtl. hilft dir der, herauszufinden, ob ein anderer Font verwendet wird, oder ob der Font geändert wurde? Bei letzterem könnte es helfen, den Font von einer XP- Maschine auf den W7- Rechner zu kopieren.

Gruß, Fiddi

@fiddi

habt ihr das Problem beide, da Du mir die Arbeitsweise erklärst
Das Problem ist mir im Grunde nur bei Copy+Paste aus Excel bekannt und unseren Anwendern konnten wir bisher bei dieser Vorgehensweise immer noch den zusätzlichen Schritt Del+Del beibringen

Wie stellt ihr Euch denn die Programmierung vor, wenn ihr alle möglichen Feldeingaben per Code korrigieren wollt?

Gruß, grolli

und unseren Anwendern konnten wir bisher bei dieser Vorgehensweise immer noch den zusätzlichen Schritt Del+Del beibringen

Alternativ könnte man auch den Anwendern beibringen, in Excel nicht das ganze Feld, sondern nur den Feldinhalt zu kopieren?

@grolli

Wie stellt ihr Euch denn die Programmierung vor, wenn ihr alle möglichen Feldeingaben per Code korrigieren wollt?

Bei reinen Textfeldern (Text/Code) kann stattdessen die Codeunit 1 ApplicationManagement,
Funktion "MakeText" aufgebohrt werden.

Gruß Torsten

Schau dir doch mal folgenden Link an.
Evtl. hilft dir der, herauszufinden, ob ein anderer Font verwendet wird, oder ob der Font geändert wurde? Bei letzterem könnte es helfen, den Font von einer XP- Maschine auf den W7- Rechner zu kopieren.

Danke, auf die Seite war ich auch schonmal gestossen, hatte auch schon überprüft, derselbe Font wie unter XP ist es. Aber den von XP zu kopieren werde ich mal noch testen.

@grolli,

Es gibt viele Gründe, warum man einzelne Felder in NAV einfügen möchte, dafür kann man keine Datenmigration einsetzen.

Naja, die User sind aber wohl keine Sonderschüler und bei einzelnen Feldern (1:1 Beziehung) werden Sie es wohl hinkriegen, nicht die Excel-Zelle sondern nur den Inhalt per Markiereren + Kopieren in der oberen Leiste und Einfügen in NAV reinzupasten.
Und wenn man das ganze noch schriftlich vereinbart als SLA und dann sagt, daß wenn sie es nicht machen, es danach keinen Support gibt, werden die Anwender irgendwann nachziehen müssen.

Eine andere Lösung wäre zu erörtern, warum Stammdaten sowohl in NAV als auch in Excel gepflegt werden müssen. Bei dieser Diskussion sollte auch der Geschäftsführer anwesend sein und eine betriebswirtschaftliche Überlegung anstellen, was billiger ist: die Anwender erziehen keine doppelte Datenhaltung mehr zu generieren, oder die IT-Abteilung weiterhin mit Opportunitätskosten zu belasten, d.h. nach Lösungen für vermeidbare Probleme suchen lassen, die nix mit dem Kerngeschäft zu tun haben (Kerngeschäft leitet sich aus Michael Porters Wertschöpfungskette ab).

Und wenn eine doppelte Datenhaltung notwendig ist, weil zB NAV keine besonders dolle CRM-Funktionalität hat, dann könnte man überlegen, Excel nur noch als Frontend zu benutzen und die Daten in ein anderes spezialisiertes Tool (CRM 4.0?) per Schnittstelle zu ziehen und aus dem Tool dann nach NAV. Vielleicht gibt es externe C#-Entwickler, die in vertretbarer Zeit zu vertretbaren Kosten eine Schnittstelle mit übersichtlicher Oberfläche mit VS.NET erstellen, so daß nach dem Knopfdruck das Excelfeld, auf dem sich der Cursor grad befindet in die richtige NAV Tabelle ohne Sonderzeichen geschrieben wird. Ist eben eine make or buy Entscheidung wo am Ende, selbst wenn das Zukaufen von Externen unvermeidbar wird, so können die Internen die Lösung als Ausgangspunkt für künftige interne Integrationsprojekte nehmen.

Falls mein Kommentar bissig wirkt: ich sehe es nicht ein, warum eine interne IT-Abteilung bei jeder Tageslaune der User wie ein dressierter Hund springen muß. Ich denke eher, daß man jeden Änderungswunsch vor dem Hintergrund der betriebswirtschaftlichen Notwendigkeit beleuchten und hinterfragen müßte und eine Kostengegeüberstellung aufstellen sollte zwischen IT-Abteilung sucht sich einen Wolf nach einer Lösung für ein künstlich generiertes Problem VS. Enduser stellen sich in deren Arbeitsweise etwas um zum Wohle der Gesamtfirma.

Wenn etwas, das jahrelang problemlos funktioniert hat, plötzlich nicht mehr klappt, ist der Gang zur Geschäftsleitung oder Entzug des Supports sicher der richtige Weg, um den Anwendern den Umstieg auf Win7 als Gewinn zu verkaufen

@Lord_British,

diese, nennen wir es mal "Sonderfunktion" , von Excel hat schon immer Probleme bereitet, nur das man es bisher sofort gesehen hat.
Wenn man das CRLF in den Daten drin lässt, gibt es Probleme beim Export von Daten oder beim Ausdruck häufiger Ärger, den man nicht sofort sieht. Das sorgt dann auch für Ärger in der IT-Abteilung, den man u.U. nur mit Hilfe des NAV-Partners (gebuchte Rechnung) wieder lösen kann. Deshalb ist es keine Frage, ob man das Problem angeht, sondern nur wo.
Ich bin der Meinung das es besser ist, man löst das Problem möglichst nahe an der Quelle, damit man hinten dran weniger Ärger hat. Außerdem finde ich besser man bekämpft die Ursache möglichst einfach, als mit irgendwelchen C# oder .net- Pflastern, die im Zweifelsfall eh nicht eingesetzt werden.

Gruß, Fiddi

Ich finde es überaus interessant, dass so eine Kleinigkeit wie das ungewollte Kopieren von CR+LF eine intensive Diskussion über das User-Verhalten und die Stellung der IT Abteilung auslöst.

Auch ich habe immer mal wieder das Problem gehabt, dass z.B. eine Übertragung von z.B. UPS Daten völlig in die Hose ging, weil einfach nur ein Name oder eine Strasse auf diesem Wege über die Zwischenablage kopiert wurde. Gleichzeitig mache ich mir nicht die geringsten Illusionen, dass alle Anwender denen ich das erklärt habe, künftig immer darauf achten werden. Insbesondere wenn das Kerngeschäft einer Firma nicht im IT Bereich liegt, wird man regelmäßig auf hochqualifizierte Mitarbeiter stoßen, die ihr Business zu 100% beherrschen, aber ansonsten absolute DAUs sind.

Auch ich denke oft, dass IT ohne Anwender richtig Spaß machen könnte, andererseits benötigt sie dann aber auch keiner mehr

Richtig wäre in diesem Fall, wenn der Anbieter unserer geliebten Software sich solcher Probleme annimmt. Firmen, die wesentlich weniger für ihre Software abgreifen, sind in solchen Dingen deutlich flexibler. Aber mit dem RTC wird ja alles besser ... außer das, was schlechter wird ...

Pidi

Hallo zusammen,

aus diesem Problem eine Diskussion über die Stellung der internen IT loszutreten ist wirklich spannend - dazu sollten wir vielleicht einen eigenen Thread öffnen.
Die IT ist ein interner Dienstleister und wird dementsprechend mit mehr oder minder schweren Problemen "behelligt".
Die Ansätze zur Erziehung der Anwender, andere Fonts, Tools installieren usw. sind nur ein Herumdoktern am Symptom, gehen aber nicht an die Ursache heran.
Sich aber seit Win 7 überhaupt mit solchen Problemen beschäftigen zu "dürfen" ist einfach nur ärgerlich und behindert das Geschäft.

Ich habe noch etwas getestet und eine Lösung gefunden.
Voraussetzung ist, dass Ihr noch einen Client mit WinXP o.ä. habt, um dort eine Konstante (c_CRLF) um die Zeichenfolge CRLF zu definieren (also die zwei Kästchen).
Beim folgenden Code ist nur darauf zu achten, dass zu suchender und zu ersetzender Text gleich lang sein müssen. Die Konstante c_Blank enthält zwei Leerzeichen. Ums hübscher zu machen, kann man die beiden Leerzeichen ja anschließend noch löschen.

Code:

SearchAndReplaceString(VAR lv_String : Text[1024])
BEGIN
  lv_StrPos := STRPOS(lv_String, c_CRLF);
  lv_TmpString := DELSTR(lv_String, lv_StrPos, STRLEN(c_CRLF));
  lv_String    := INSSTR(lv_TmpString, c_Blank, lv_StrPos);
END;


Gruß
42

Hallo 42,

das ist natürlich auch eine, wenn auch vom Programmieraufwand her aufwendige, Lösung. Man muss diesen Code in jedes Feld einbauen.

Aber wenn du das in Code machen willst, geht das so glaube ich einfacher

Das CRLF steht immer am Ende des eingefügten Text, und wenn es doch noch an anderer Stelle stehen sollte gehört das in NAV da auch nicht hin .

Code:

SearchAndReplaceString(VAR lv_String : Text[1024])
VAR
  c_CRLF@10000: text[2];
BEGIN
  c_CRLF[1] := CHR(10);
  c_CRLF[2] := CHR(13);
  lv_String :=DELCHR(lv_String, '=',c_CRLF);
END;

wenn du c_CRLF als globale Variable am Anfang des Programms zuweist, muss das auch nicht immer bei jedem Aufruf tun.

Gruß, Fiddi

@fiddi

... Man muss diesen Code in jedes Feld einbauen.

es geht auch einfacher:

Bei reinen Textfeldern (Text/Code) kann stattdessen die Codeunit 1 ApplicationManagement,
Funktion "MakeText" aufgebohrt werden.

Gruß Torsten