---

struktur.jpg

Hi Forum,

folgendes Problem:
In einer geschachtelten Familientabelle (siehe Anhang) soll ein Parameter "SAP" unterschiedlich gesteuert werden.
Ist dieser Parameter im obersten generischen Modell (hier "g.prt") in der Familientabelle eingatregen, kann man diesen nicht mehr in einer untergeordneten Familientabelle (hier z.B. "i1.prt") ansteuern.
Gut, dachten wir, tragen wir den Parameter in den aufgerufenen Modellen direkt ein, und nicht in der Familientabelle. Sozusagen "von unten nach oben". Klappte auch. Nur: wenn man dann den Parameter im obersten generischen ändert, sind auch alle anderen Modelle geändert. Geht also nur über die Steuerung in Familientabellen, und das gibt hat mecker (siehe oben).
Eine Auflösung der Familientabelle (wenigstens auf nur eine Ebene)  steht nicht zur Diskussion, weil die Modelle recht oft Verwendung finden.

Hat jemand eine Idee?

Grüße

Detlef Bexkens

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

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

---

Hallo Detlef,

warum interessiert Euch eigentlich der Parameter im generischen Teil? Wenn Ihr den an der Stelle vernachlässigt, könnt Ihr ihn noch in den untergeordneten Tabellen benutzen und alles wird schön. Eine Änderung im generischen hat dann auch keine Folgen mehr für die Familienmitglieder, da der Stand ja in der Tabelle festgenagelt ist.

_____________
Gruß
U_Suess

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

---

Hi U,

der Kunde benutzt diesen Parameter, um ein Zusatzprogramm anzusteuern, welches die Objekte (oder Stammdaten daraus) übertragen soll. Es könnte demnach sein, das einmal ein generisches Objekt übertragen werden soll, und ein andermal halt nicht. Drum.
Eine Diskussion über Vor- und Nachteile von geschachtelten Familientabellen hift dort momentan auch nicht, weilŽs halt schon seit einigen Jahren gemacht wird. Das Kind ist also schon tief im Brunnen und wir wollen vermeiden, das der Zulieferer der Schnittstelle für jede Familientabellen-Ebene einen eigenen Paremeter hinzufügen muss. Vielleicht gibtŽs ja was eleganteres.

Viele Grüße

Detlef

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

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

---

Hallo

Es stört doch aber nicht, wenn der Parameter des generischen Teiles nicht in einer Tabelle festgenagelt ist. Er kann doch dort eingestellt werden, ohne das andere Teile davon betroffen sind, vorausgesetzt, man setzt in den Tabellen den Wert und nutzt dort nicht den "*" für den default-Wert.
Ansonsten bleibt sicher nur die Möglichkeit, für jede Ebene einen extra Parameter anzulegen. Allerdings könnte man so etwas dann sicher über Beziehungen auf einen einzigen Wert bringen. Das setzt aber z.B. voraus, daß es gewisse Regeln für diesen Parameter gibt. Was besseres fällt mir jetzt auch nicht ein.

Gruß
Udo

PS: Eine Diskussion über Schachtelungen in Tabellen wollte ich nicht anfangen, da es Dir bei Deinem Problem auch nicht wirklich hilft.

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

---

Tach

wir arbeiten bei uns wohl mit derselben SAP Schnittstelle
denn ASSIGN kommt mir sehr bekannt vor.
Also die Firma die die Schnittstelle programmiert hat
hat uns darauf hingewiesen, das es nicht möglich ist mit
Familientabellen zu arbeiten, wenn die SAP relevanten
Attribute in Intralink eingetragen werden.
Denn dort kann ich bekanntlich nur die Attribute des generischen Teils
einstellen, die der Varianten nicht!
Wir erwarten eine Lösung in der Ilink 3.3, wurde uns jedenfalls
gesagt das das dort geht?!
Arbeitet dein Kunde zufällig mit intralink?

Mein geschreibsel hilft vielleicht nicht richtig weiter,
aber ich kenn das leidige "Schnittstellenproblem".

Gruß
undertaker

------------------
bisschen Pfeffer???

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

---

Hi Undertaker,

jepp. Der Kunde hat Intralink 3.2 also müssen wir die Lösung rein in Pro/E suchen.
Die ersten Tests zur Änderung von Ausprägungen der Attribute innerhalb von Familientabellen aus dem WS heraus haben wir letztens recht erfolgreich in der 3.3 kombiniert mit Wildfire vorgenommen - ein paar klitzekleine Besonderheiten gibtŽs aber noch. Inwiefern genau diese Problematik damit gelöst werden könnte, weiß ich noch nicht. Und dann gehtŽs bestimmt nicht für die 2001er.

Viele Grüße

Detlef

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

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

---

Äh ich bin ein bisschen verwirrt. Mein Vorschlag wäre folgender, allerdings hab ich nicht ganz verstanden, ob Du das mit "von unten nach oben" und "zusätzliche Parameter" ohnehin bereits angedeutet hast:

SAP wird auf oberster Ebene mit in die Tabelle aufgenommen und halt auf "NO" oder "ASSIGN" gesetzt. Ein zweiter Parameter SAP_2 wird im Generic (und damit auf den Varianten der obersten Ebene) auf "" gesetzt.

SAP_2 wird auf zweiter Ebene in die Familientabelle aufgenommen und auf "NO" oder "ASSIGN" gesetzt, je nachdem.

In der Beziehung des Teils steht dann:
IF SAP_2 != ""
  SAP = SAP_2
ENDIF

Würde das helfen, oder ist das bereits ein Weg, der durchgedacht wurde?

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

---

Hi Stahl,

sowas meine ich mit einer eleganten Lösung! Warum ist mir das selbst nicht eingefallen?! Ich habe schon mit der Kollegin vor Ort gesprochen, sie wirdŽs mal testen.

Danke, 10U4u

Detlef

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

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

---

Danke für die Blumen! 

Stahl.

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