Sortierung von Code Feldern auf SQL Server 2005
17. Juni 2008 14:46
Hallo zusammen!
Ich habe folgendes Problem:
Ich habe in einer Navision Native Datenbank bei den Artikeln folgende Sortierung der Artikelnummern:
1
2
3
10
11
12
Wenn ich dieselbe Datenbank in meinem SQL Server importiere, öffne und mir die Artikel anschaue werden sie wie folgt sortiert:
1
10
11
12
2
3
Ich habe mittlerweile herausgefunden das der SQL Server die Code Felder als Text behandelt und deshalb auch so sortiert. Ich möchte aber die Sortierung wie in der Native Datenbank. Hat jemand eine Idee wie man das machen könnte?
Vielen Dank im Voraus!
Ich habe folgendes Problem:
Ich habe in einer Navision Native Datenbank bei den Artikeln folgende Sortierung der Artikelnummern:
1
2
3
10
11
12
Wenn ich dieselbe Datenbank in meinem SQL Server importiere, öffne und mir die Artikel anschaue werden sie wie folgt sortiert:
1
10
11
12
2
3
Ich habe mittlerweile herausgefunden das der SQL Server die Code Felder als Text behandelt und deshalb auch so sortiert. Ich möchte aber die Sortierung wie in der Native Datenbank. Hat jemand eine Idee wie man das machen könnte?
Vielen Dank im Voraus!
17. Juni 2008 15:17
du könntest die Artikelnummern wie folgt aufbauen:
01
02
03
.
.
.
10
11
Dann sortiert der SQL-Server auch richtig. Falls die Artikel schon Posten haben, wird es etwas aufwendiger, da alle Postentabellen auch geändert werden müssen.
und damit dasselbe Problem nicht wieder bei 100 oder 1000 Artikel auftritt, vielleicht gleich mit 0001 anfangen, bzw. unsere Artikel fangen immer bei 1000 oder sogar 10000 an.
01
02
03
.
.
.
10
11
Dann sortiert der SQL-Server auch richtig. Falls die Artikel schon Posten haben, wird es etwas aufwendiger, da alle Postentabellen auch geändert werden müssen.
und damit dasselbe Problem nicht wieder bei 100 oder 1000 Artikel auftritt, vielleicht gleich mit 0001 anfangen, bzw. unsere Artikel fangen immer bei 1000 oder sogar 10000 an.
17. Juni 2008 16:20
Technisch kann dieses Problem auch gelöst werden, indem in den betroffenen "Code" Feldern die Eigenschaft "SQLDataType" auf "Variant" (oder "Integer") gesetzt wird.
Das müsste dann allerdings auch in allen Tabellen-Feldern erfolgen, die via Table-Relation auf dieses Feld referenzieren ... und ist mit ein paar "wenn & aber" verbunden ...
Das müsste dann allerdings auch in allen Tabellen-Feldern erfolgen, die via Table-Relation auf dieses Feld referenzieren ... und ist mit ein paar "wenn & aber" verbunden ...
17. Juni 2008 16:24
das mit den "wenn & aber" würde mich mal sehr interessieren. was muss noch dabei beachtet werden?
17. Juni 2008 16:55
Nun ja:
1. Erstmal müssen die Table-Relations überprüft werden, je nachdem wie umfangreich das ist müssen ggf. relative viele Felder geändert werden. Technisch geht das zwar mit ein paar Zeilen Code ziemlich einfach, aber man hat u.U. dann jedesmal Trouble wenn Upgrades/Patches/etc. eingespielt werden müssen.
2. Wird "Integer" verwendet, dann können - logisch - keine alphabetischen Zeichen mehr in diesen "Code" Feldern verwendet werden. Damit schränkt man die Möglichkeiten von diesen Feldern erheblich ein; deshalb wird i.d.R. lieber "Variant" verwendet.
3. Weder "Integer" noch "Variant" können mit führenden Nullen umgehen; gab es vorher die Datensätze 01, 001, 0001, so würde es nun drei mal die 1 geben bzw. eine Primärschlüsselverletzung ...
Die genannte Tabelle "Artikel" ist eben etwas heikel, da sie SEHR HÄUFIG benutzt wird, und entsprechend viele Änderungen notwendig sind. Muss man den PK in den Datensätzen der Tabelle ändern, so müsste man auch SEHR VIELE andere Datensätze nachziehen (Preistabellen, Artikelposten, Belege, uvm.) ...
1. Erstmal müssen die Table-Relations überprüft werden, je nachdem wie umfangreich das ist müssen ggf. relative viele Felder geändert werden. Technisch geht das zwar mit ein paar Zeilen Code ziemlich einfach, aber man hat u.U. dann jedesmal Trouble wenn Upgrades/Patches/etc. eingespielt werden müssen.
2. Wird "Integer" verwendet, dann können - logisch - keine alphabetischen Zeichen mehr in diesen "Code" Feldern verwendet werden. Damit schränkt man die Möglichkeiten von diesen Feldern erheblich ein; deshalb wird i.d.R. lieber "Variant" verwendet.
3. Weder "Integer" noch "Variant" können mit führenden Nullen umgehen; gab es vorher die Datensätze 01, 001, 0001, so würde es nun drei mal die 1 geben bzw. eine Primärschlüsselverletzung ...
Die genannte Tabelle "Artikel" ist eben etwas heikel, da sie SEHR HÄUFIG benutzt wird, und entsprechend viele Änderungen notwendig sind. Muss man den PK in den Datensätzen der Tabelle ändern, so müsste man auch SEHR VIELE andere Datensätze nachziehen (Preistabellen, Artikelposten, Belege, uvm.) ...
20. Juni 2008 16:07
Hallo!
Erstmals danke für die vielen Antworten.
@Patrick
Leider sind in dieser Datenbank schon einige Tausend Artikel vorhanden.
@stryk
Kann das ganze wirklich so aufwändig sein...? In der Navision Native Datenbank stimmt die Sortierung ja perfekt. Nur durch das Importieren in die SQL Datenbank wird alles anders sortiert. Kann man vielleicht was im SQL Server verändern??
Erstmals danke für die vielen Antworten.
@Patrick
du könntest die Artikelnummern wie folgt aufbauen:
01
02
03
Leider sind in dieser Datenbank schon einige Tausend Artikel vorhanden.
@stryk
Kann das ganze wirklich so aufwändig sein...? In der Navision Native Datenbank stimmt die Sortierung ja perfekt. Nur durch das Importieren in die SQL Datenbank wird alles anders sortiert. Kann man vielleicht was im SQL Server verändern??
21. Juni 2008 10:14
Nun, das Problem bei der Sache ist, dass sich native NAV im Bezug auf Sortierung von Code Feldern nicht an sonst übliche Standard gehalten hat ...
Der Datentyp "Code" ist ein alphanumerischer; also sollte auch alphanummerische sortiert werden (so wie es der Rest der Welt macht) - macht aber "Native" nicht, hier wird nummerisch sortiert ...
SQL Server hält sich nun mal an diese ISO Standards und sortiert korrekt - blöderweise wiederspricht das dem NAV-Eigenbau ...
Um das Problem zu lösen, kenne ich nur den Weg, den "SQL Data Type" zu ändern. Ich habe aber auch schon Gerüchte gehört, dass durch die Verwendung von speziellen Code-Pages und Collations ebenfalls das Sortierverhalten angepasst wird. Aber ich halte das ehrlich gesagt für Märchen, und selbst wenn es das gäbe, dann hätte NAV ein Problem damit:
"Text" in NAV wird ja auch korrekt alphanummerisch sortiert. Da sowohl "Text" als auch "Code" im SQL Server zu "varchar" werden, würde eine solche globale Änderung auch die "Text"-Felder betreffen, und diese dann plötzlich auch nummerisch sortieren ... d.h. das Problem würde nur verschoben werden ...
IMHO bleibt nix andres übrig, als den "SQL Data Type" da zu ändern wo's notwendig ist.
Aber wie schon gesagt, technisch ist das kein großer Aufwand, da man die notwendigen Änderungen per C/AL in der Tabelle "Field" erreichen kann. D.h. um den "SQL Data Type" von Item."No." zu ändern müsste man in "Field" das Feld 27/1 ändern, und danach alle Felder die "RelationTo" 27 haben ...
Der Datentyp "Code" ist ein alphanumerischer; also sollte auch alphanummerische sortiert werden (so wie es der Rest der Welt macht) - macht aber "Native" nicht, hier wird nummerisch sortiert ...
SQL Server hält sich nun mal an diese ISO Standards und sortiert korrekt - blöderweise wiederspricht das dem NAV-Eigenbau ...
Um das Problem zu lösen, kenne ich nur den Weg, den "SQL Data Type" zu ändern. Ich habe aber auch schon Gerüchte gehört, dass durch die Verwendung von speziellen Code-Pages und Collations ebenfalls das Sortierverhalten angepasst wird. Aber ich halte das ehrlich gesagt für Märchen, und selbst wenn es das gäbe, dann hätte NAV ein Problem damit:
"Text" in NAV wird ja auch korrekt alphanummerisch sortiert. Da sowohl "Text" als auch "Code" im SQL Server zu "varchar" werden, würde eine solche globale Änderung auch die "Text"-Felder betreffen, und diese dann plötzlich auch nummerisch sortieren ... d.h. das Problem würde nur verschoben werden ...
IMHO bleibt nix andres übrig, als den "SQL Data Type" da zu ändern wo's notwendig ist.
Aber wie schon gesagt, technisch ist das kein großer Aufwand, da man die notwendigen Änderungen per C/AL in der Tabelle "Field" erreichen kann. D.h. um den "SQL Data Type" von Item."No." zu ändern müsste man in "Field" das Feld 27/1 ändern, und danach alle Felder die "RelationTo" 27 haben ...
21. Juni 2008 14:14
stryk hat geschrieben:Nun, das Problem bei der Sache ist, dass sich native NAV im Bezug auf Sortierung von Code Feldern nicht an sonst übliche Standard gehalten hat ...
Genau diese Sortierung war vor etlichen Jahren eines der damaligen Verkaufsargumente für den Wechsel zu Navision. In älteren Datenbanksystemen waren vielfach nur nummerische Artikelnummern möglich. Mit dieser Sortierungweise war es nun möglich, Daten aus Altsystemen zu übernehmen, ohne das sich dabei für die Anwender die gewohnte Reihenfolge ändert, und trotzdem für die Zukunft die Option zu haben, alphanummerische Artikelnummern zu verwenden.
23. Juni 2008 13:42
Ok, dann werd ich mir die Tabelle mal vornehmen!
Vielen Dank für die Information!! Ich finde das echt super, das Ihr Euch die Zeit nehmt für unsere Problemchen
Schöne Grüße von Jürgen
Vielen Dank für die Information!! Ich finde das echt super, das Ihr Euch die Zeit nehmt für unsere Problemchen
Schöne Grüße von Jürgen
Re: Sortierung von Code Feldern auf SQL Server 2005
15. Dezember 2008 13:47
Hallo.
Ich habe eine Lösung für das Problem entwickelt.
Filter wie folgt:
Früherer Filter zum Beispiel:
100..500|600|700..1000|1601..1607
Um jetzt keine Probleme mehr mit der SQL Sortierung zu haben, ist der neue Filter so:
(100..500&???)|(600&???)|(700..999$???)|(1000&????)|(1601..1607&????)
Dieser Filter gibt das Richtige Ergebnis aus. Allerdings kommt die Anzeige von Tabellen damit nicht so 100% klar.
Am besten nur im Code für Filterungen bei Berichten nehmen.
Ciao
Ich habe eine Lösung für das Problem entwickelt.
Filter wie folgt:
Früherer Filter zum Beispiel:
100..500|600|700..1000|1601..1607
Um jetzt keine Probleme mehr mit der SQL Sortierung zu haben, ist der neue Filter so:
(100..500&???)|(600&???)|(700..999$???)|(1000&????)|(1601..1607&????)
Dieser Filter gibt das Richtige Ergebnis aus. Allerdings kommt die Anzeige von Tabellen damit nicht so 100% klar.
Am besten nur im Code für Filterungen bei Berichten nehmen.
Ciao
Re: Sortierung von Code Feldern auf SQL Server 2005
15. Dezember 2008 15:12
Das mit der Sortierung war bei einem Kunden von uns auch mal ein Problem... nach langem hin und her überlgen ob man das nun so wie stryk beschrieben hat löst oder so belässt hat man sich darauf geeinigt das sich die Anwender halt umstellen müssen
"Sie sollen ja nicht nach Artikelnummern gehen..." sonder nach der Bezeichnung usw.... es ist halt schon ein ganz schöner Aufwand alle Tabellen zu durchwühlen und das so anzupassen wie das vorher war. Und bei nem Update gibts dann evtl. Probleme. Ist auf jeden Fall der geringste Aufwand für die It´ler das auf dem weg abzuwickeln 
"Sie sollen ja nicht nach Artikelnummern gehen..."
sonder nach der Bezeichnung usw.... es ist halt schon ein ganz schöner Aufwand alle Tabellen zu durchwühlen und das so anzupassen wie das vorher war. Und bei nem Update gibts dann evtl. Probleme. Ist auf jeden Fall der geringste Aufwand für die It´ler das auf dem weg abzuwickeln