---

Eine Baugruppe ist in TCE eingetragen, Eigentümer ist die Gruppe "Konstrukteure".
"infodba" trägt die Baugruppe aus und zwar
a) als Mitglied der Gruppe "dba": das dauert ca. 1 Minute, die BG ist in NX dann "schreibgeschützt"
b) als Mitglied der Gruppe "Konstrukteure": Das dauert dann 10 (in Worten: zehn!) Minuten

Wie kann man sich diese bemerkenswerte Performancedifferenz erklären?

------------------
Gruß
UdoMM
:
<><

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hi,

was sagt denn der rechtebaum? dba hat natürlich auf alles leserechte. wenn die baugruppen entsprechend groß und die rechtestruktur entsprechend fein ist, ist dieser performanceunterschied recht einfach zu erklären. viele abfragen innerhalb des tce's, ob der anwender x in der gruppe y mit der rolle z diese daten überhaupt sehen/ändern/speichern darf.
was den schreibschutz betrifft: es gibt für den dba den bypass, damit ist auch das schreibrecht auf alle teile der db da - ohne den schalter ist es nur ein schutz vor der eigenen dummheit...
frage: welche baugruppengröße? ist der ruletree vergewaltigt worden (ausgefeiltes rechte-/rollenkonzept)?

------------------
Gruß aus Hamburg

Yeti

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo, erstmal danke für die rasche Antwort.
Leider ist hier gar nichts im Rechtebaum definiert außer dem Standard. Es gibt auch keine Stati, die auf die Parts gesetzt sind, deren Rechte ausgewertet werden müssten.
Das selbe (langsame) Ergebnis konnte mit jeder anderen Gruppenzugeörigkeit erreicht werden, die nicht die Owning-Group ist.

Unangenehmerweise haben wir nun auch feststellen müssen, dass sich dieser Effekt auch auf die Erstellung von Zeichnungsansichten auswirkt - mit Zeitunterschieden zwischen 1:30 Minuten pro Ansicht bis zu 6 Minuten.

Der infodba kann natürlich den Rechtebaum bypassen, aber wir wollen ja auch gerne mal produktiv arbeiten... 

Also sind wie weiter auf der Suche nach dem Verursacher dieses Phänomens und für Hinweise, die zur Ergreifung des Täters führen, immer recht dankbar.

------------------
Gruß
UdoMM
:
<><

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

ich tippe mal auf sehr komplizierte Beziehungen zwischen Teilen: nutzt ihr WAVE, UDFs etc.?

------------------

Gruß  ,

PLMboy

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ja, Hallo erstmal...
In der Test-Baugruppe wurden keine WAVE-links, Interpart-Expressions sowie auch keine UDFs verwendet.
Die Testbaugruppe wurde „normal“ aufgebaut, lediglich PDW-Normteile sind darin verbaut, (sowie selbst erstellte Abzugskörper), die mit dem Pocket-Tool des PDW abgezogen worden sind.

------------------
Gruß
UdoMM
:
<><

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo UdoMM,
versuch mal folgendes:
1) UGII_DRAFT_SUPPRESS_THREAD_TRUE_HIDDEN_LINE=1
2) UGII_UGMGR_TCM_V91_Enhancements=DISABLED

Zu 1): Schaltet die Berechnung von Kurven als verdeckte Kanten aus (neu in NX4, dauert bei vielen Gewinden und Zeichnungen sehr lange)
Zu 2): Behebt Probleme bei BG-Teilefamilien (in NX4)

Ausserdem:
set NR_BYPASS=ON und
ugmgr_add_note_types -u=... -p=... -g=... ausführen
(dadurch werden die Seedparts/UDF's neu angelegt), danach evtl. die UDF-Ordner in TCE prüfen (wenn Ihr die benutzt)

make_datasettype -u=infodba -p=<password> -g=dba -definition=ugmanager_exports.dat
kann auch helfen.

Gruss
Deepblue

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nach einer App-Share Sitzung mit UGS hat sich gezeigt, dass in der SQL-Datenbank einige Indixe nicht gesetzt waren und dadurch die Verzögerung zustande kam.
Indexe wurden erzeugt, nun sind die Ladezeiten in Ordnung!

------------------
gruß

Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP