[gelöst] CHANGECOMPANY

[sweikelt]

Hallo liebe NAV-Gemeinde,

ich habe einen Report geschrieben, der die Dimensionen aktualisiert.
In diesem Report werden verschiedene DataItems durchlaufen.
Funktioniert alles perfekt, bis auf die CHANGECOMPANY funktion

-> diese rufe ich im DataItem Company auf

"DL-Rubrik".CHANGECOMPANY(Company.Name);
Customer.CHANGECOMPANY(Company.Name);
Dienstleistung.CHANGECOMPANY(Company.Name);
Objektleiter.CHANGECOMPANY(Company.Name);
"DL-Objekt".CHANGECOMPANY(Company.Name);
"DL-Position".CHANGECOMPANY(Company.Name);

Nun werden zwar die verschiedenen mandanten durchlaufen, allerdings werden nur die Daten im aktuellen Mandanten geändert.
Wie kann ich die Daten aller Mandanten verändern/aktualisieren?

vielen Dank im Voraus

Zuletzt geändert von sweikelt am 13. Januar 2011 13:32, insgesamt 1-mal geändert.

Bitte ein Codebeispiel für eine deiner Tabellen.

Erste Regel beim Umgang mit CHANGECOMPANY: Es kann im Zielrecord nicht mit Triggern gearbeitet werden. Tabu sind daher:

Code:

Rec1.VALIDATE(...);
Rec1.INSERT/MODIFY/DELETE/RENAME(TRUE); // nur das TRUE ist tabu

Werden dennoch Trigger verwendet, so werden sie auf den aktuellen Mandanten angewendet statt auf den Zielmandanten.

IF g_boolVorgabeAnlegen THEN BEGIN
IF txtRubrik <> '' THEN BEGIN
g_recDim."Table ID" := 5079153;
g_recDim."No." := Code;
g_recDim."Dimension Code" := txtRubrik;
g_recDim."Dimension Value Code" := Code;

IF NOT g_recDim.INSERT(TRUE) THEN
g_recDim.MODIFY(TRUE);
END;
END;

==========

also werd ich mal die true's rausnehmen und hoffen, dass es funktioniert^^

erstmal vielen dank für die hilfe. ich meld mich, sobald ich klarheit hab :D

Erwischt

Stell die den CHANGECOMPANY wie einen externen Zugriff von Nicht-NAV auf die NAV-DB vor: Dort hast du nur die Feldinhalte im Zugriff und kannst keinerlei Businesslogik (sprich: Programmierung dahinter) ausführen.

so,

auf jedenfall bin ich nun schlauer im Umgang mit ChangeCompany, allerdings funktioniert es immernoch nicht richtig. ich werd das ganze jetzt mal auseinander nehmen und schauen, was ich falsch gemacht habe.

ich betrachte mein problem allerdings als gelöst, da es mit meinem vorherigen ansatz ja garnicht hätte funktionieren können

vielen dank natalie ;)

Da fällt mir auf:

Code:

"DL-Rubrik".CHANGECOMPANY(Company.Name);
Customer.CHANGECOMPANY(Company.Name);
Dienstleistung.CHANGECOMPANY(Company.Name);
Objektleiter.CHANGECOMPANY(Company.Name);
"DL-Objekt".CHANGECOMPANY(Company.Name);
"DL-Position".CHANGECOMPANY(Company.Name);

Hier vermisse ich die Recordvariable g_recDim.
Kann es sein, dass du für diese Variable das CHANGECOMPANY vergessen hast?

Oh, siehe da - es läuft doch!

hatte die globale Variable wirklich nicht eingebunden.
Ich dachte, die DataItems würden reichen.
wie schaut es mit lokalen Record-Variablen aus - muss ich diese ebenfalls mit

recCust.CHANGECOMPANY(Company.Name); dazu bewegen, ihre Daten in allen Mandanten zu verändern?

Natalie, du bist meine Retterin!

Wenn du erst Zugriff auf eine Variable hast, dann ist es egal, ob sie global oder lokal ist. Sie wird überall gleich benutzt.
Heißt für dich: Auf jeden Fall immer CHANGECOMPANY.

Du ersparst dir aber viel Stress und Sucherei, wenn du in deinem Report CHANGECOMPANY an einer zentralen Stelle für alle globalen Varialben ausführst.
DataItems sind nichts anderes als globale Variablen, siehe viewtopic.php?f=19&t=10806#DataItems-Variable
Die erste von dir genannte Codestelle war also schon ganz richtig. Die kannst du noch um ggf. globale Variablen ergänzen. Auf lokale Recordvariablen würde ich an deiner Stelle verzichten.

Ok, vielen vielen Dank, das hat mir sehr weitergeholfen!

Ich habe in meinem Report nur globale Variablen, wollt es aber für die Zukunft wissen.
Bin ich wieder ein Stückchen schlauer.

Code:

IF NOT INSERT THEN MODIFY

Das ist gefrickelt und SQL suboptimal.
Besser:

Code:

IF NOT ISEMPTY THEN MODIFY ELSE INSERT


Veto, Jan.
ISEMPTY funktinoiert zum einen nur dann richtig, wenn du vorher entspr. Filter (hier auf alle Primärschlüsselfelder) setzt.
Und der Performance"verlust" dürfte ohne ISEMPTY derart gering sein, dass sich der Zusatz an Quelltext hierfür nicht lohnt.

Mann man schon ein unnötiges INSERT bzw. MODIFY unterbinden möchte, dann eher mit IF NOT GET - aber das ist auch kein Gewinn.
Ergo: Ich würde es genauso machen wie beschrieben: IF NOT INSERT THEN MODIFY.

Von Anfang an am optimalsten machen, dann spart man sich den Codereview in der Zukunft.
IF NOT GET ist aber auch eine gute Alternative.