Hi,
dauert wieder etwas länger, könnte aber interessant sein. Es geht um die neue Funktion der 3.2 "Libraray Conflicts" beim CheckOut.
"Libraray Conflicts" werden dadurch erzeugt, das z.B. innerhalb einer auszucheckenden Baugruppenstruktur zwei Baugruppen auf ein und dieselbe Familientabelle zugreifen. Ist normalerweise ja auch nichts besonderes, wird aber dann interessant, wenn die eine Baugruppe eine bestimmte Variante haben will, die es vielleicht in einer höheren Version der Familientabelle nicht mehr gibt. In dieser höheren Version der Familientabelle gibt es aber eine Variante, die unbedingt von einer anderen Baugruppe gebraucht wird. Da hat also ein Anwender eine Variante gelöscht, die noch Verwendung hat und später wurde dann die Familientabelle erweitert. Dumm ist dann halt nur, wenn beide Baugruppen auf einmal ausgescheckt werden sollen.
"Libraray Conflicts" zeigt uns an, das wir etwas auswählen sollen. Beim CheckOut muss man also ab der 3.2 darauf achten, das dieser Schalter nicht aktiv (grau) ist. Ist dieser Schalter aktiv (schwarz), besteht das Problem und INTRALINK kann nicht selbst entscheiden, was wir wollen (Bild 1-CheckOut).
Wenn wir den Schalter aktivieren, zeigt uns INTALINK eine Liste der zur Verfügung stehenden Versionen der Familientabelle an und darin die Varianten je Version. Man kann dann eine Version auswählen, welche dann ausgecheckt wird (Bild 2-ConflictList).
Ok, soweit zur Theorie, nur um eine allgemeine Grundlage zu schaffen. Folgendes Szenario möchte ich mit den INTRALINKern diskutieren, die es bereits bis hier ausgehalten haben und vielleicht neugierig geworden sind:
Ausgangslage
- Baugruppe mit Unterstruktur im CS
- In Unterstruktur mehrere Unterbaugruppen
- In einigen Unterbaugruppen werden Varianten aus einer Familientabelle verwendet
Änderung 1
- Neuen WS erzeugen und eine der Unterbaugruppen auschecken
- Aufruf der Baugruppe und Ersetzen einer der Komponenten durch eine „Schwester“-Variante. Speichern
- Im generischen Modell löschen der vermeindlich nicht mehr gebrauchten Variante (ätsch, wird sie doch noch, nur dummerweise in einer Baugruppe, die nicht ausgecheckt wurde).
- Im WS liegt nun die Baugruppe als „geändert“ und das generische Modell als „geändert“. Klar, das nur das generische Modell ein „+“ bekommt, und nicht die Varianten. Was interessiert es schließlich eine Variante, ob eine „Schwester“ mehr oder weniger da ist?!.
- CheckIn von Baugruppe und generischem Modell
Auswirkung 1
- Neuen WS anlegen
- Im CS die Hauptbaugrupe markieren und auschecken als „Latest“.
- Es wird interessanterweise KEIN "Libraray Conflicts" angezeigt., obwohl von meiner Logik her, einer da sein sollte.
Änderung 2
- CheckOut der Familientabelle mit der gelöschten Varianten
- Änderung der Familientabelle (z.B. ein Maß oder auch nur Folien), damit alle Varianten und das generische Modell als geändert markiert sind.
- CheckIn der Familientabele
Auswirkung 2
- Neuen WS anlegen
- Im CS die Hauptbaugruppe markieren und auschecken als „Latest“.
- Es wird ein "Libraray Conflicts" angezeigt.
- Umschalten im CheckOut-Fenster auf „AsStored“
- Es wird wieder KEIN "Libraray Conflicts" angezeigt. Klaro, s.o.
Folgende Fragen:
1. Warum wird beim Hinzufügen einer Variante ALLE Varianten und das generische Modell als geändert gekennzeichnet?
2. Warum wird beim Löschen einer Variante nur das generische Modell als geändert gekennzeichnet?
3. Gibt es Anwender/Firmen die immer alle Varianten in der Version heraufsetzen?
4. Gibt es Anwender/Firmen die es so wollen, das eine Varianten nur dann in der Version heraufgesetzt wird, wenn diese auch wirklich verändert wurde?
Ich selbst bin mir nicht ganz im klaren darüber.
Einerseits besteht meine langjährige Tätigkeit in Normung und Stücklistenwesen darauf, das Varianten natürlich nur dann versioniert werden, wenn sie auch wirklich verändert wurden.
Andererseits sagt der Pro/E-Logiker in mir was anderes, weil der CheckOut (siehe Auswirkung 1) keinen "Libraray Conflict“ erzeugt.
Oder kann ich die Schuld den Programmierern zuschieben, um weiter ruhig schlafen zu können?
Stellungnahmen, Kommentare oder Richtigsetzung meiner Logik sind willkommen.
Viele Grüße
Detlef
------------------
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP