[Gelöst] Artikelnummer umbenennen

Hallo zusammen,

ich hab hier noch ein Problem und weiß nicht wie ich es angehen soll.

Und zwar müssen wir bei jedem Artikel (selektiert nach Artikelkriterien) in Navision eine 0 an die Artikelnummer anfügen und die per Report.
Sowas habe ich noch nie gemacht.

Hat jemand einen Lösungsvorschlag?

MFG
Tom

Zuletzt geändert von Brainwolf am 27. August 2008 08:06, insgesamt 1-mal geändert.

Im OnAfterGetRecord des Reports im DataItem Item z.B.

Code:

Item2.GET("No.");
Item2.RENAME("No." +'0');

Wegen der vielen Table Relations auf die Artikeltabelle kann das aber etwas dauern, je nach Postenanzahl und Hardware.
Bei manchen Addons ist allerdings der Rename für die Artikeltabelle gesperrt, z.B. wenn DB-Replikation verwendet wird.

Ein Hinweis noch allgemein zum Umbenennen:

In einem 4.00 SP3 Client haben wir damals auch, ich glaube irgend etwas unwichtigeres wie Zahlungsformen, umbenannt. Grundsätzlich funktionierte das auch prima. Aber einige der Tabellen in denen die Zahlunsgsform als Relation definiert war, waren mandantenübergreifend, also DataPerCompany=No.

Genau die Werte dieser Tabellen hat NAV damals nicht geändert. Ob das ein Problem des Clients war und ob der Fehler oder das Feature ggf. behoben wurde, kann ich nicht sagen. Wenn ihr also ggf. die Eine oder Andere globale Tabelle habt...

BTW: Identifizieren kann man mandantenübergreifende Tabellen sehr einfach, indem man in Tabelle Object auf TableData mit leerem Mandantenfeld filtert...

BTW: Identifizieren kann man mandantenübergreifende Tabellen sehr einfach, indem man in Tabelle Object auf TableData mit leerem Mandantenfeld filtert...

Oder - wenn man es ohne Programmcode mal einsehen möchte:
Menü Datei -> Datenbank -> Information -> Tabellen
Ganz am Anfang der Liste stehen Tabellen ohne Mandantennamen. Diese sind mandantenunabhängig.

Für SQL-Freaks:
Im SQL Management Studio enthalten die mandantenabhängigen Tabellen den Mandantennamen am Anfang, bei den mandantenunabhängigen steht dort (logischerweise) kein Mandantenname.

Super, vielen dank.

Genau das brauch ich so.

Ich bins nochmal,

nun ist aber ein problem aufgetaucht.

Und zwar wenn ein Artikel umbenannt wird, kommt die Fehlermeldung dass der Artikel schon exisitert.

Wie bekomme ich es so hin, dass er den Artikel überspringen soll, wenn die Zielartikelnummer schon exisitert?

Ich habe bisher das so gelöst, wenn der Rename erfolgreich dann Boolean-Wert auf Item=True, also kann ich den Report mehrmals ausführen und somit werden die schon umgesetzten ARtikelnummern noch nochmal genommen.

Ich habe bisher das so gelöst, wenn der Rename erfolgreich dann Boolean-Wert auf Item=True, also kann ich den Report mehrmals ausführen und somit werden die schon umgesetzten ARtikelnummern noch nochmal genommen.

Statt das Ergebnis des RENAMEs abzufragen, würde ich ein GET auf die potenzielle neue Artikelnummer machen:

Code:

REPEAT 
  DeineNeueNummer := SetzeNeueNummer;
UNTIL NOT Artikel2.GET(DeineNeueNummer);
Artikel.RENAME(...)

Entweder mache ich da etwas falsch oder der Report dauert wirklich so lange. Hab das nach 20min. mal abgebrochen.

Code:

REPEAT 
  NewNo := Item."No."+'0';
UNTIL NOT Item2.GET(NewNo);
Item.RENAME("No." +'0');
Item."Artikelnr geändert" := TRUE;
MODIFY;


Entweder mache ich da etwas falsch oder der Report dauert wirklich so lange. Hab das nach 20min. mal abgebrochen.

Beim Umbenennen prüft NAV sämtliche Verweise in allen Tabellen und würde diese dann mit Umbenennen, daher kann das (besonders bei größeren Datenbanken) einige Zeit in Anspruch nehmen.
Deine Lösung, die bereits umbenannten Artikel entsprechend zu kennzeichnen ist daher schon sehr schlau.

Mein Tipp: Sofern möglich, starte die Umbenennung nach Feierabend und breche sie morgens vor Arbeitsbeginn ab, damit die anderen Anwender arbeiten können.
Damit deine bisherigen Umbenennungen nicht verloren gehen, solltest du in regelmäßigen Abständen einen COMMIT einbauen (z. B. alle 100 Datensätze).

Dass das Umbenennen einige Zeit braucht ist mir bekannt.

Allerdings habe ich das untenstehende Skript beim start nur mit einem Artikel ausprobiert. <-- 20min+ ?

Entweder mache ich da etwas falsch oder der Report dauert wirklich so lange. Hab das nach 20min. mal abgebrochen.

Code:

REPEAT 
  NewNo := Item."No."+'0';
UNTIL NOT Item2.GET(NewNo);
Item.RENAME("No." +'0');
Item."Artikelnr geändert" := TRUE;
MODIFY;


Mir fällt nur gerade auf, eigentlich sollte es so lauten:

Code:

...
Item.RENAME(NewNo); // Nicht Item."No." + '0', da sonst evtl. im Widerspruch zur getesteten NewNo
...


Wenn dieser Quelltext im DataItem Item eines Reports steht und du auf "Artikelnr. geändert" = FALSE filterst, würde ich mit einer Kopie arbeiten:

Code:

REPEAT 
  NewNo := Item."No."+'0';
UNTIL NOT Item2.GET(NewNo);
Item2 := Item;
Item2.RENAME(NewNo); // Nicht Item."No." + '0', da sonst evtl. im Widerspruch zur getesteten NewNo
Item2."Artikelnr geändert" := TRUE;
Item2.MODIFY; // Hier unbedingt wie bei RENAME oder "Aritkelnr. geändert" die richtige Recordvariable verwenden!

Dass das Umbenennen einige Zeit braucht ist mir bekannt.

Allerdings habe ich das untenstehende Skript beim start nur mit einem Artikel ausprobiert. <-- 20min+ ?

also, das mit ca. 20 Minuten kann ich bestätigen (seit dem wir vom alten auf den neuen Server gewechselt haben, dauert es aber nur noch so 12-15 Minuten) Aber da kann ja niemand richtigarbeiten während der Zeit (auch nicht in anderen Mandanten auf der gleichen Datenbank)

Habe nun den Report über 17 Stunden laufen lassen und ich habe nur einen Artikel ausgewählt.

Bitte um eine andere Lösung.

Wie gesagt, meine Idee war, dass wenn er beim rename der Artikelnummer prüft ob diese schon existiert. Wenn ja, soll er diese übergehen und die nächste machen.

Meine Idee war auch zuerst die 7Stelligen Artikelnummern auszuwählen und danach die 6Stelligen. Da würden wir auch auf kein Problem stoßen aber wir haben SQL-Server mit seiner komischen SQLZahlen sortieren dass die 10 gleich nach der 1 kommt und danach die 2.

Hab nun hinbekommen.

Code:

Item.GET("No.");
NewNo := Item."No."+'0';

IF Item.GET(NewNo) THEN
 CurrReport.SKIP
 ELSE
 Item.RENAME(NewNo);

Item."Artikelnr geändert" := TRUE;
MODIFY;


Noch einmal, und auch wenns mit deinem Performanceproblem erst einmal nichts zu tun hat: dein MODIFY zeigt ins Nirvana ... Es muss die gleiche Recordvariable wie "Artikelnr geändert" haben.

Hat es doch!?!
Ich habe doch nicht die Variable geändet. Bleibe doch auf der Item.

Hat es doch!?!
Ich habe doch nicht die Variable geändet. Bleibe doch auf der Item.

Falls Item dein DataItem ist (oder eine Recordvariable, die du in einer Schleife durchläufst), dann ist das hier im OnAfterGetRecord-Trigger ... problematisch:

Code:

Item.GET("No.");
...
IF Item.GET(NewNo) THEN
...
Item.RENAME(NewNo);

Dann solltest du hierfür eine eigene Recordvariable, z.B. Item2 statt Item, verwenden.

Item müsste für den korrekten Schleifendurchlauf des DataItems unangetastet bleiben.
Dies könnte auch Performanceprobleme verursachen.

PS (weil ich mittlerweile glaube, dass dir das noch nicht 100%ig bewusst war und wenn doch, bitte ignorieren):
Sämtliche Record-Befehle wie GET, INSERT, MODIFY, FIND etc. wirken sich nur auf die aktuelle Recordvariable aus, mit der sie verwendet wird - selbst wenn mehrere Recordvariablen auf die gleiche Tabelle zeigen. Beispiel:
Stell dir vor, du hättest einen Artikel mit dem Namen 'ABC' und drei Recordvariablen Item1, Item2, Item3.

Code:

// zu diesem Zeitpunkt sind alle drei Variablen komplett leer
Item1.GET('ABC'); // kopiert alle Inhalte des Artikels ABC in die Variable Item1.
// Item2 und Item3 bleiben weiterhin leer!
Item2.Name := 'Neuer Name'; // funktioniert, allerdings ist Item2 bis auf den Namen weiterhin leer!
Item3.MODIFY; // führt  zum Laufzeitfehler "Artikel <leer> existiert nicht", da Item3 noch immer komplett leer, d.h. auch ohne Artikelnummer
Item1.MODIFY; // kein Fehler, da du allerdings in Item1 nichts geändert hast, bleibt der Datensatz zu Artikel ABC unverändert.

Oh, wieder was gelernt.

Danke für deine Anleitung!

Also wieder zurück zu deinem Quelltext
Ich nehme noch immer an, dass Item dein DataItem in einem Report ist.
Dann würde ich eine zweite Recordvariable Item2 auf diese Weise im OnAfterGetRecord-Trigger verwenden:

Code:

NewNo := "No."+'0';

IF Item2.GET(NewNo) THEN
  CurrReport.SKIP;

Item2 := Item;
Item2.RENAME(NewNo);
Item2."Artikelnr geändert" := TRUE;
Item2.MODIFY;

Sorry das ich den alten Thread hier ausgrabe

Ich soll für einen neuen Lieferanten Datanorm Artikel importieren.
Beim Import kann ich aber das ArtikelNr Format nicht festlegen (ich kann nur einen eigenen Nummernkreis auswaehlen oder die Kreditor Artikel Nr übernehmen).

Nun sollen die neuen Artikelnummern sich aus 'RO'+Suchbegriff zusammen setzen , soweit so gut, funktioniert auch mit RENAME, nur das es pro Artikel mindestens ca. 20 minuten dauert. 55.000 Artikel soll ich umbenennen.....

Das würde heißen 20 min * 55 Tsd Artikel = 1100000min/60 = 183333 std / 24 = 763 Tage / 365 = 2 Jahre ?????

Die Artikel haben 100% keine gebuchten Posten.

Bevor ich jetzt anfange die Datanorm Schnittstelle zu modifizieren würde ich gerne wissen ob es auch ohne RENAME irgendwie schnell geht.

Danke.
Gruß
Peter

Wenn keine Postenlasten hinten dran hängen, würde ich sie kopieren, löschen und mit richtiger Nummer neu einfügen.

Außer Posten gibt es aber noch viele weitere Tabellen, die eine TableRelation auf die Artikeltabelle haben. Dazu müsste auch der Dataport geprüft werden,wenn der Datanormimport keine weiteren Daten schreibt ( Preise etc.) und aus der Artikeltabelle auch keinen weiteren Einträge in anderen Tabellen im INSERT-Trigger erzeugt werden, sollte es kein Problem sein den Datensatz zu kopieren und unter der neuen Nummer neu einzufügen und gleichzeitig den alten zu löschen. Wenn doch, müssen die anderen Tabellen auch analog behandelt werden. Ein solches Verfahren ist aber nur für diesen Spezialfall mit neuen Artikeln geeignet.

Hi Kowa,

habe schon gemerkt das da noch andere Tabellen hinter hängen, z.b. Mengenbasiseinheitencode,
und auch andere Tabellen wo eine Relation zum Artikel ist.

Ich werde also versuchen das ganze schon beim Datanorm Import zu handlen. Wenn das nicht geht, bzw. ich nicht hinbekomme,
dann hmm... weiß noch nicht ...

danke schonmal für eure Antworten

Peter

mal kurz zur Performance,
wenn es sich machen lässt, in einer C/Side Datenbank geht das umbenennen mitunter deutlich schneller als in SQL.

Ich werde also versuchen das ganze schon beim Datanorm Import zu handlen.

Wenn der Dataport normale Dataport Fields verwendet, kann im OnBeforeEvaluateField-Trigger ein gelesener Feldinhalt direkt manipuliert werden. Da kann man den "RO"-Präfix vorsetzen bzw. besser da universeller einen variablen Code, den man unter "Optionen" eingeben kann, als Prä- oder Postfix für die Artikelnr. verwenden. Die maximale Länge von insgesamt 20 Stellen darf dabei natürlich nicht überschritten werden.