[Gelöst] Rename ist sehr langsam
14. Januar 2010 12:33
Hallo
Kann es sein, dass ab Version 5.x das Renamen von Datensätzen extrem lange dauert?
Wenn ich auf der Kundendatenbank (3.7) einen Artikel rename und anschliessend das Gleiche mit 5 SP1 oder 2009 mache, dauert das ca. 4x so lange.
Insbesondere die Gebuchten Belegzeilen dauern enorm lange.
Unter 3.7 hat es gereicht, z.B. in Tabelle 111 einen Key auf das Feld "No." zu machen.
Unter 5 wird dieser Key ignorriert und immer der PK verwendet.
Sehr merkwürdig.
Hat dieses Verhalten auch schon jemand beaobachtet.
Danke für jegliche Hinweise.
Martin
Kann es sein, dass ab Version 5.x das Renamen von Datensätzen extrem lange dauert?
Wenn ich auf der Kundendatenbank (3.7) einen Artikel rename und anschliessend das Gleiche mit 5 SP1 oder 2009 mache, dauert das ca. 4x so lange.
Insbesondere die Gebuchten Belegzeilen dauern enorm lange.
Unter 3.7 hat es gereicht, z.B. in Tabelle 111 einen Key auf das Feld "No." zu machen.
Unter 5 wird dieser Key ignorriert und immer der PK verwendet.
Sehr merkwürdig.
Hat dieses Verhalten auch schon jemand beaobachtet.
Danke für jegliche Hinweise.
Martin
Zuletzt geändert von martinst am 14. Januar 2010 19:58, insgesamt 1-mal geändert.
Re: Rename ist sehr langsam
14. Januar 2010 15:51
Beim einem RENAME wird ja der Primary Key verändert, und unter meiner 5.1 Datenbank
habe ich diesbezüglich noch keine besonders schlechte Performance beobachtet. Und wenn
man sich in den älteren Versionen vor VSIFT mal die SQL Tabellen-Trigger und den darin
enthaltenen Code angeschaut hat, würde man eher dort die schlechte Performance vermuten,
obschon die VSIFT Indizes natürlich auch aktualisiert werden wollen ...
Allerdings finde ich es auch erstaunlich, wenn gebuchte Belegzeilen renamed werden. Ich habe
hier an die 1 Millionen Rechnungs-Belege, also mehrere Millionen Zeilen und das gilt damit
auch für Lieferscheine (wg. Tab 111). Hier würde aber aus Sicht buchhalterischer Grundsätze
niemand auf die Idee kommen (vorberhaltlich der fehlenden Lizenz dafür) gebuchte Belege zu
verändern. Deshalb kann ich in dieser Größenordnung keine Aussage dazu machen.
Da hier aber auch die Artikel-Tabelle erwähnt wurde; Navision rattert doch dann auch noch durch
jede Tabelle in der ein Feld eine relation auf die Artikelnummer hat, und das könnte in verschiedenen
Datenbanken mit verschiedenen BW Versionen ja auch sehr unterschiedlich sein ...?
Pidi
habe ich diesbezüglich noch keine besonders schlechte Performance beobachtet. Und wenn
man sich in den älteren Versionen vor VSIFT mal die SQL Tabellen-Trigger und den darin
enthaltenen Code angeschaut hat, würde man eher dort die schlechte Performance vermuten,
obschon die VSIFT Indizes natürlich auch aktualisiert werden wollen ...
Allerdings finde ich es auch erstaunlich, wenn gebuchte Belegzeilen renamed werden. Ich habe
hier an die 1 Millionen Rechnungs-Belege, also mehrere Millionen Zeilen und das gilt damit
auch für Lieferscheine (wg. Tab 111). Hier würde aber aus Sicht buchhalterischer Grundsätze
niemand auf die Idee kommen (vorberhaltlich der fehlenden Lizenz dafür) gebuchte Belege zu
verändern. Deshalb kann ich in dieser Größenordnung keine Aussage dazu machen.
Da hier aber auch die Artikel-Tabelle erwähnt wurde; Navision rattert doch dann auch noch durch
jede Tabelle in der ein Feld eine relation auf die Artikelnummer hat, und das könnte in verschiedenen
Datenbanken mit verschiedenen BW Versionen ja auch sehr unterschiedlich sein ...?
Pidi
Re: Rename ist sehr langsam
14. Januar 2010 16:05
Hallo Pidi
Ich habe vergessen zu sagen:NATIV nicht SQL
Ob die gebeuchten Belegzeilen geändert werden oder nicht, kann der Benutzer ja gar nicht entscheiden.
Sobald er die Artikelnummer ändert, wird durch das TableRelationPropertie in NAV bestimmt.
Die Relation dort zu brechen, wäre zwar möglich. Sobald aber ein solcher Beleg dann in einen neuen Beleg kopiert, haben wir ein neues Problem (Artikel xy exisitiert nicht).
Ich habe aber das Problem vermutlich gesehen. Meiner Meinung nach ist es das Feld BOM Item No. in den Tabellen Sales Line Archive, Item Ledger Entry etc.
Ich versuche mal, ob ich dort mit einem neuen Key was verbessern kann.
Ich orientiere wieder.
Gruss
Ich habe vergessen zu sagen:NATIV nicht SQL
Ob die gebeuchten Belegzeilen geändert werden oder nicht, kann der Benutzer ja gar nicht entscheiden.
Sobald er die Artikelnummer ändert, wird durch das TableRelationPropertie in NAV bestimmt.
Die Relation dort zu brechen, wäre zwar möglich. Sobald aber ein solcher Beleg dann in einen neuen Beleg kopiert, haben wir ein neues Problem (Artikel xy exisitiert nicht).
Ich habe aber das Problem vermutlich gesehen. Meiner Meinung nach ist es das Feld BOM Item No. in den Tabellen Sales Line Archive, Item Ledger Entry etc.
Ich versuche mal, ob ich dort mit einem neuen Key was verbessern kann.
Ich orientiere wieder.
Gruss
Re: Rename ist sehr langsam
14. Januar 2010 19:58
Problem gelöst.
Es war in der Tat so, dass einfach ein paar Schlüssel neu gemacht werden mussten.
Unter anderem:
Tabelle Item
Feld Alternative Item No.
Tabelle Item Ledger Entry
Feld Originally Ordered No.
Tabelle Sales Line Archive
Feld Originally Ordered No.
etc.
Bsp eines Kunden:
Vor Anlegen der Schlüssel dauerte das Renamen ca. 8 Minuten pro Artikel
Nach Anlegen ca. 2-3 Sekunden.
gruss
Es war in der Tat so, dass einfach ein paar Schlüssel neu gemacht werden mussten.
Unter anderem:
Tabelle Item
Feld Alternative Item No.
Tabelle Item Ledger Entry
Feld Originally Ordered No.
Tabelle Sales Line Archive
Feld Originally Ordered No.
etc.
Bsp eines Kunden:
Vor Anlegen der Schlüssel dauerte das Renamen ca. 8 Minuten pro Artikel
Nach Anlegen ca. 2-3 Sekunden.
gruss