[Gelöst] ModifyAll beschleunigen?

Hallo

Ich habe im Moment das Problem, dass im Rahmen eines Upgrades alle kundenspezifischen Felder aus den Standardtabellen entfernt werden muss.
Zu diesem Zweck habe ich mir eine Routine geschrieben welche mir den nötigen C/AL-Code erzeugt um die Felder zu "leeren".

Der fertig erzeugte Code, sieht dann ca. so aus:

Code:

d.OPEN('"Lagerposten" -> "EAN-Code"');
Lagerposten.RESET;
Lagerposten.SETFILTER("EAN-Code", '<>%1', '');
RecRef.GETTABLE(Lagerposten); 
IF GetBestKey(RecRef) THEN <----------------------- Danke an Timo Lässer
  Lagerposten.SETVIEW(RecRef.GETVIEW);
IF Lagerposten.FINDSET THEN
  Lagerposten.MODIFYALL("EAN-Code", '');
COMMIT;
d.CLOSE;


Das Problem ist einfach die Dauer.
Wir haben bei diesem Kunden ca. 5'000'000 Lagerposten (Artikelposten).
Pro Feld dauert das ca. 20 Minuten. Und es sind eben eine Menge Tabellen und eine Menge Felder
Gibt es einen Trick ModifyAll irgendwie zu beschleunigen.
Ach ja, Nativ nicht SQL

Danke für alle Hinweise.

Martin

Zuletzt geändert von martinst am 3. Februar 2010 14:12, insgesamt 1-mal geändert.

Alle Sekundärschlüssel deaktivieren, die vom Upgradetoolkit nicht benötigt werden. Das kann man über eine Form für die Tabelle "Key" zügig erledigen. Das Schlüsselerstellen beim Wiederaktivieren dauert natürlich etwas, unter dem Strich ist es aber so schneller.

Kann ich eben nicht.
Die meisten zu entfernenden Felder haben einen Key.
Wenn ich diesen Key entferne, geht vermutlich das Schreiben schneller, dafür braucht Navision unendlich lange bis die zu ändernden Datensätze gefunden werden.
(Tabelle xy wird durchscht.....).
Die Idee mit den Keys verfolge ich aber weiter.
Ich mache es nun so:
- Keys deaktivieren
- blanken der Felder in repeat until

Danke

Hallo Martinst,

der Modifyall ist nicht in jedem Fall die schnellere Funktion.

Wenn du mehrere Felder in einer Tabelle löschen möchtest, ist die gute alte "Repeat .. until next = 0" auf dem Primärschlüssel ohne Filter immer noch die schnellere Wahl, und dann hilft kowa's- Tip dir weiter. Ebenso würde ich nicht lange abfragen, ob das Feld leer ist, sondern einfach den Nullsetzungswert zuweisen.

Gruß, Fiddi

Hallo

Genau so habe ich das auch gemacht.
Alles mit REPEAT UNTIL.
Ohne Abfrage auf leer werden alle Felder mit CLEAR gelöscht.

Ich habe nun alle nicht benötigten Keys in der Ursprungstabelle und alle Sekundärschlüssel in der Zieltabelle entfernt.
Der Kopiervorgang läuft im Moment noch, scheint aber massiv schneller zu sein!!!!!!

Gebe genaue Zahlen (Zeiten) bekannt sobald ich sie weiss.

ModifyAll scheint aber in diesem Fall wirklich nicht so toll zu sein

Gruss

Hallo

Die Variante mit Repeat until ist die Bessere als ModifyAll.
Insbesondere nach Deaktivierung der Sekundärschlüssel.
Die Zeit des Kopiervorgangs ist von 16 Std. auf 3,5 Std. gesunken

Vielen Dank

da die eh weg müssen, lässt sich sowas nicht schnell über einen SQL Befehl bewirken?

da die eh weg müssen, lässt sich sowas nicht schnell über einen SQL Befehl bewirken?

Auf der NATIV-DB?
Via ODBC?

Gruss

und lässt sich das ins Upgrade-Toolkit integrieren?

und lässt sich das ins Upgrade-Toolkit integrieren?

Sorry. Überfordert!
Was meinst Du mit diesem Satz?

Gruss

war eine Ergänzung zu dem was du davor geschrieben hast.
Ich war davon ausgegangen, dass du für das Upgrade auch das Upgrade-Toolkit verwendet hast, was noch andere Vorteile bietet, wie z.B. das Unterbrechen des Upgrades und aufsetzen nach der letzten komplett bearbeiteten Tabelle.

Gruß, Fiddi

war eine Ergänzung zu dem was du davor geschrieben hast.

Ach so. Ja ich verwende das Upgrade-Toolkit.
Allerdings mache es eben so, dass ich zuerst mit einer Verarbeitung alle Tabellen mit Anpassungen in neue Tabellen kopiere und die Inhalte der kundenspezifischen Felder lösche.
Und das dauerte eben solange.
Danach kann das Upgrade-Toolkit ohne Anpassungen verwendet werden.
Am Schluss kopiere ich die Inhalte der kundenspezifischen Felder wieder in die (angepassten) Standardtabellen zurück und lösche die zuvor erstellten Tabellen wieder.

Gruss

@martinst
hab oben das Nativ nicht gelesen.

mit sql befehl wird nur direkt auf dem SQL Server funktionieren.
wäre aber interessant in solchen Fällen ob das einen Geschwindigkeitsvorteil bringt.

@martinst,

dann dauert dein Update ja doppelt so lange wie nötig .

Du machst erst einen Lauf, der die Kundenfelder sichert, womöglich in eigenen Tabellen.
Dann lässt du das UGT Step 1 laufen, das die gleichen (relevanten Tabellen ) noch einmal mit der gleichen Funktionalität durchläuft und auch noch zwei Felder sichert und löscht.
Danach kommt UGT- Step 2, der die gesicherten Tabellen bzw. die vorhandenen Felder verarbeitet, bzw. zurück kopiert.
Zu guter Letzt kommt dein Step 2, der wieder die kundenspezifischen Felder füllt.

Das mit dem Standard UGT ist zwar schön und gut, aber es lässt sich so einfach erweitern, dass es aus meiner Sicht, keinen Grund gibt es nicht zu erweitern, um die eigenen Felder zu sichern, bzw. zu verarbeiten. Den wesentlichen Teil des Codes, der in die UGT- Funktionen kommt hast du ja eh schon geschrieben.

Gruß, Fiddi

Es geht.
Wenn der Update über mehrere Versionen auf einmal gehen soll. Finde ich das nicht so schlecht.
Die ganze kopierer auf meiner Seite dauert nun noch ca. 5 Std.
Das macht auf die ganze Zeit, die das Update dauert dann nicht mehr viel aus.
So muss ich aber die Upgrade-Objekte nicht anfassen.

Gruss

noch ein Tipp,
das löschen und diese Schleifendurchläufe gehen wesentlich schneller, wenn du die Datenbank vorab technisch konvertierst.
bis version 4 oder 5 wurde das Programm zum ende hin immer langsamer.

Danke.

Mach ich aber bereits so. Die Datenbank wird ganz am Anfang des Upgrade-Prozedere mit der neuen Version angelegt und das FBK importiert.

Gruss