[gelöst]Probleme mit dem Zeichensatz ?

[rainergaiss]

Hallo,

ich bin beim Update einer "historischen" Datenbank (Version 5, nativ) auf 2017. Schritte: 5 --> 2009R2 --> 2009R2 SQL --> 2013 --> 2017. Vor dem Einlesen des Backups in SQL habe ich den Fieldcheck gemacht, hat auch funktioniert. Nun bleiben 2 Restprobleme:

1.
Die Artikelnummern sind sehr exotisch, von 1 bis 6 Stellen, mal mit, mal ohne Buchstaben. Die meisten sind aber numerisch, und die Sortierreihenfolge soll möglichst wie in der nativen DB sein. Ich habe das gelöst mit dem SQL-Datentyp Variant. Da werden zwar die alphanumerischen Artikelnummern vor den numerischen sortiert, womit ich aber leben kann. Nun hat der Kunde aber auch Artikelnummern wie 007, und die werden beim Einlesen in z.B. dann 7 konvertiert. Der Kunde hat aber auch einen Artikel 5 und einen 005 (ich bin für diesen Blödsinn nicht verantwortlich!), und da heißt es beim Einlesen, der Artikel sei schon vorhanden, was ja durchaus stimmt. Kann man dieses Verhalten irgendwie ändern?

2.
PLZ und Ort. In der nativen DB existieren z.B. zwei Datensätze, "12345 Gießen" und "12345 Giessen". Das gibt beim Einlesen in SQL einen schon vorhandenen Datensatz. Lässt sich da etwas ändern?

Jede Idee ist willkommen.

Zuletzt geändert von rainergaiss am 11. Januar 2018 15:59, insgesamt 1-mal geändert.

Hallo,

es gibt bei mibuso ein Fieldchecktool, das ist erstens erheblich schneller, und kann zweites auch Sonderzeichen suchen und soviel ich weiß auch ersetzen. Es gibt noch ein weiteres Problem wenn beim Einlesen und der Konvertierung von ß nach ss das Feld zu lang wird. Auch dass kann man damit lösen.

Zu den Artikelnummern: da bleibt dir nur die Lösung über die gleiche Länge oder ein vorangestellten Buchstaben. Mit Variant würde ich nicht arbeiten.

Gruß Fiddi

Mit Umstellungen auf Variant gab es auch schon massive Perfomanceprobleme, z.B. siehe letzten Kommentar hier.
https://rebunavdiary.wordpress.com/2014/08/15/code-fields-sorting/
Das kann jederzeit wieder hochkommen. Daran, dass Vornullen da nicht zulässig sind, kann man auch nichts ändern.

Vielen Dank erstmal!

Zu den Artikeln: Wie kann man einem Kunden beibringen, dass er jetzt erst einmal tausende von Artikelnummern ändern soll. Was ihr hier geschrieben habt, finde ich insofern toll, weil es mir genau das bestätigt, was mich ärgert. Die Variant-Lösung ist die einzige, die z.B. das Filtern ähnlich wie bisher zulässt. Andererseits war / ist mir neu, dass es zu solchen Performanceproblemen kommen wird. Wir sprechen hier von mehr als 11000 Artikeln.

Zu den PLZ: Ich verwende nur das mibuso-Tool, aber leider kann es nicht herausfinden, dass es bei zwei Datensätzen zum selben Primärschlüssel kommen kann. Grundsätzlich kann es ja mehrere Schreibweisen geben, nur wenn der gleiche Ort mit gleicher PLZ einmal so und einmal so geschrieben ist, dann kracht es eben. Das war bei dem Kunden auch noch nie ein Thema, aber anscheinend haben die einen neuen Sachbearbeiter der meint, es sei modern, wenn man statt ß lieber das ss benützt. Dabei sind die Eigennamen ja nie bei der Reform mit umgestellt worden. Selbst der Schloßplatz in Stuttgart heißt noch immer so, und auch die Litfaßsäule wird nicht anders geschrieben, weil der Erfinder eben Litfaß hies. Hier würde ich doch eher der nativen Datenbank die "Schuld" geben. Meines Wissens nach ist auch PLZ+Ort die einzige Situation in NAV, die zu diesem Problem führen kann. Ich glaube wir sollten dem Kunden einen Testreport verkaufen, bezahlen kann den ja der Sachberabeiter.

Gruß
Rainer

1. Artikel 5 und einen 005


2. "12345 Gießen" und "12345 Giessen".

Jede Idee ist willkommen.

Die Lösung heisst: "lieber Kunde, das geht so nicht. Vor der ERP-Neueinführung ist zwingend ein Projekt namens Master-Data-Management und Bereinigung durchzuführen"

Was du hier machst: du versuchst operativ ein Problem zu lösen, welches strategisch entstanden ist.

100% einverstanden! Wie verklickert man das den "da muss es doch noch etwas anderes geben"-Leuten?

Hallo,

prüf nochmal die Einstellungen in der Datenbank im SQL-Client unter Sortierung, da konnte man glaube ich mit der Groß/Kleinschreibung was hin mogeln. (ich glaube ausschalten)

Aber 11000 Artikel sind doch eher Spaß.
Musste gerade bei einem Kunden den Test- Bericht für das Inventurbuchblatt heftigst überarbeiten, weil er bei 110000 Artikeln immer mit OutOfMemory- Fehler abgestürzt ist. Jetzt läuft er wenigstens als PDF.

Gruß Fiddi

Aber 11000 Artikel sind doch eher Spaß.

Das stimmt, für die Performance der Flowfields am Artikel ist aber nur die Postenanzahl (Artikel- bzw. Wertposten etc.) maßgebend.

Ca. 1 Mio Artikelposten, 2 Mio. Wertposten. Die PLZ kann man theoretisch mit drüberschauen aussortieren.

Aber 11000 Artikel sind doch eher Spaß.

Das stimmt, für die Performance der Flowfields am Artikel ist aber nur die Postenanzahl (Artikel- bzw. Wertposten etc.) maßgebend.

Die Postenanzahl ist nur marginal ein Problem. Was man eingrenzen muss ist die Anzahl der Posten die für die konkrete Flowfield- Berechnung benötigt werden.

Übrigens hat die DB 5.6 Mio- Artikelposten und 9,7 Mio. Wertposten und ca. 13,4 Mio. Sachposten. Das Update von NAV 4 nach NAV2015 hat (ohne Dimensionen) gut 8 Stunden gedauert.

Gruß Fiddi

Das mit der Performance scheint durchaus ein Problem werden zu können. Was ist eigentlich, wenn man die Artikelnr. noch einmal in der Nummer 2 mitführt und dieses Feld Variant macht? Dann verlagern wir die Performance-Probleme in die Auswertungen wo sie uns nicht weh tun.

Anderer Vorschlag/Frage:

das Problem tritt doch eigentlich nur in Übersichten und beim Filtern (Artikelfilter '1..2' findet auch 10,11,1111,,,,,) auf.

Die Übersichten könnte man durch ein Sortierfeld lösen, das einen Wert enthält, der korrekt sortiert, und nach dem die Übersichten standardmäßig sortiert werden.

Problematisch werden Artikelnummernfilter mit Bereichen, da nützt dir auch Nummer2 nichts.

Gruß Fiddi

Nummer2 wäre eigentlich so ein Sortierfeld, aber du hast recht, bei Bereichen nutzt es genauso wenig. Damit ist die Möglichkeit auch vom Tisch.

Wir lassen gerade den Kunden überlegen.

Gruß
Rainer

Eine Idee wäre noch:

Artikelnummern-> Code alle gleiche Länge, also mit '0' auffüllen. (viel Spaß beim umrubeln der Posten & Belege), und Nummer 2 als Suchfeld, damit Sie Zeit haben sich um zu gewöhnen.

Gruß Fiddi

Kunde hat entschieden. Er akzeptiert die standardmäßige SQL-Sortierung.

Vernünftige Entscheidung, das ist ja dann auch laut ISO-Norm . Auf Integer sollte man den SQLDataType übrigens auch nicht umstellen, führt auch zum Performanceeinbruch, das hatte ich hier schon mal verlinkt.