 |
- 5.8.2.1.15.29.1. Auflösungscheck - Anwendungsfall
- 5.8.2.1.15.29.2. Auflösungscheck - Voraussetzungen/Vorbereitungen
- 5.8.2.1.15.29.3. Auflösungscheck - Kataloganalyse
- 5.8.2.1.15.29.4. Auflösungscheck - Aktivierung
- 5.8.2.1.15.29.5. Auflösungscheck - Analyse nach Katalogänderungen
- 5.8.2.1.15.29.6. Reverse Search – Bestellnummernsuche Testen
- 5.8.2.1.15.29.7. Auflösungscheck - Besondere Hinweise
- 5.8.2.1.15.29.8. Auflösungscheck - Konfig-Einstellungen
- 5.8.2.1.15.29.9. Reverse Search – Auflösungscheck (automatisch) - Problematische Konstrukte vermeiden
Ist die Zahl der Kombinationsmöglichkeiten, die sich aus Wertebereichen ergeben zu groß, wird nicht indexiert, sondern eine Reverse Search eingesetzt, welche ebenfalls erfolgreiches Finden der Wertebereichswerte ermöglicht.
Damit Bauteile via Suche nach Bestellnummer bzw. Typcode gefunden werden können, auch die, bei denen CNSORDERNO und CNSTYPECODE aus Wertebereichswerten aufgebaut sind, müssen bestimmte Voraussetzungen erfüllt sein.
Der Auflösungscheck prüft, ob Kataloge im Volltextsuch-Index auflösbar sind oder ob eine Reverse Search notwendig ist. Ist der Katalog entsprechend vorbereitet, kann auch in den komplexesten Fällen erfolgreich mit Bestellnummer bzw. Typcode gesucht werden.
Die Benefits einer Reverse Search sind:
Immer gute Suchergebnisse, da eben auch die aus komplexen Wertebereichswerten (gelbe Felder) aufgebauten Bestellnummern (Artikelnummern) bzw. Typenschlüssel gefunden werden.
Via Bestellnummer / Typenschlüssel können Artikel auf PARTcommunity-Portalen sicher gefunden und korrekt bestellt werden. Querverlinkung von Portalen ist möglich. Externe Assistenten können statt mit einer komplexen Deeplinkliste auch über den Aufruf von Artikelnummer/Typenschlüssel direkt Geometrie anfordern.
Initiale Artikelzuordnung von ERP-Nummer zu PARTsolutions Projekten auf Basis von Bestellnummer / Typcode wird vereinfacht, da diese absolut eindeutig sind ("Urfüllung").
Siehe auch Abschnitt 5.12.7.2, „Benefits der Klassifizierung nach CNSORDERNO und CNSTYPECODE“.
Klassifizierung nach CNSORDERNO und/oder CNSTYPECODE
![[Wichtig]](https://webapi.partcommunity.com/service/help/latest/pages/de/installation_ecatalogsolutions/doc/images/important.png)
Wichtig Informationen zur Unterscheidung von CNSORDERNO und CNSTYPECODE, also wann nach was zu klassifizieren ist, finden Sie unter Abschnitt 5.12.7, „Klassifizierung nach CNSORDERNO / CNSTYPECODE“.
Diese Aufgabe kann für den ganzen Katalog halbautomatisch mit dem Plugin Projekte im Batchlauf klassifizieren (siehe Abschnitt 5.12.6, „Projekte im Batchlauf klassifizieren“) erledigt werden.
Im Ergebnis erfolgt dann ein Eintrag unter Variable mit Bestellnummer und/oder Variable mit Typenschlüssel.
Aktualisieren Sie den Volltextsuchindex (wenn nicht bereits automatisiert geschehen).
Sofern in den Einstellungsoptionen von PARTproject die Option Volltextsuchindex bei Änderungen automatisch aktualisieren nicht aktiviert war, müssen Sie dies jetzt unbedingt selbst manuell via PARTadmin ausführen (siehe Abschnitt 1.3.8.6.3, „Volltextsuchindex“ in PARTsolutions - Handbuch für Administration).
Aktualisieren Sie den Volltextsuchindex (wenn nicht bereits automatisiert geschehen).
Sofern in den Einstellungsoptionen von PARTproject die Option Volltextsuchindex bei Änderungen automatisch aktualisieren nicht aktiviert war, müssen Sie dies jetzt unbedingt selbst manuell via PARTadmin ausführen (siehe Abschnitt 1.3.8.6.3, „Volltextsuchindex“ in PARTsolutions - Handbuch für Administration).
Bevor Sie die Analyse starten, stellen Sie sicher, dass die existierende
resolvecheck.cfgin Ihrem lokalen Katalogverzeichnis gelöscht ist. Ansonsten wird der Auflösungscheck die bestehenden Ergebnisse aus der existierenden Datei verwenden.![[Hinweis]](https://webapi.partcommunity.com/service/help/latest/pages/de/installation_ecatalogsolutions/doc/images/note.png)
Hinweis Nach jeder Analyse wird unter
$CADENAS_DATA/23dlibs/<catalogname>die Konfigurationsdateiresolvecheck.cfgerzeugt, die zentral alle Ergebnisse auflistet.Löschen Sie diese vor einem erneuten Lauf, um wieder ein sauberes Ergebnis zu erhalten.
[REVERSEANALYSIS] pfad/projectname.prj=GEOMDATE;Tabellenzeilen;Varianten;Automatische Suche möglich (0 oder 1)z.B. project.prj=01.01.2019;1;10;1 ... ... ganz unten [COMMON] REVERSEANALYSIS=Datum des letzten Laufs
Ein erneuter initialer Prüflauf kann auch automatisiert via Konfig-Einstellung erzwungen werden. Siehe Abschnitt 5.8.2.1.15.29.8, „Auflösungscheck - Konfig-Einstellungen“.
Rufen Sie im Kontextmenü des gewünschten Katalogs unter Automatisierung den Befehl Reverse Search – Auflösungscheck (automatisch) auf.
Nach beendetem Prozess erscheint eine entsprechende Meldung, ob der Katalog vollständig aufgelöst werden kann oder nicht.
Ein initialer Auflösungscheck kann je nach Kataloggröße einige Zeit in Anspruch nehmen. Hat sich bei erneutem Aufruf nichts oder wenig verändert, wird nach wenigen Sekunden wieder das Ergebnis angezeigt. Es werden nur geänderte Projekt getestet.
-> Die Ergebnisse des Auflösungschecks werden im Dialogfenster Auflösungsergebnisse detailliert angezeigt.
Die Spalte Anzahl zeigt die Varianten pro Projekt. Bei Projekte ohne Wertebereiche ist der Wert gleichbedeutend mit der Anzahl Tabellenzeilen und bei Projekte mit Wertebereichen gibt der Wert die Anzahl der Varianten an bzw. wenn leer, dann sind die Varianten über 25000 (Limitwert, weiter wird nicht geprüft).
In der Spalte Projekte gibt der Zahlenwert in Klammern an, wieviele Projekt es in der jeweiligen Kategorie gibt.
Die folgende Tabelle zeigt die Bedeutung der Icons.
Ein oder mehrere Teile unter diesem Knoten sind noch nicht gelöst. Das blaue Ausrufezeichen steht für verschiedene Möglichkeiten:
Klassifikation fehlt (Projekte wurden ignoriert)
Der Teilbereich ist auf die eine oder andere Art gelöst und benötigt keine Aufmerksamkeit mehr:
----------------------------------------------------------------------------------------
Projekte mit nicht relevantem Wertebereich (Dimensionsmerkmal)
Die automatische Auflösung war zwar erfolgreich, allerdings enthält die Bestellnummer bzw. der Typcode eine unzulässige Wertebereichsvariable vom Typ Funktionsmerkmal oder Dimensionsmerkmal.
Hinweis Details hierzu finden Sie unter Abschnitt 7.8.13, „Typ-Identifikation“.
Zu diesem Projekt ist eine manuelle Reversekonfiguration hinterlegt. (<projektname>_pnoreverse.cfg vorhanden) 
Projekt wird aufgelöst in den Luceneindex geschrieben. Die folgende Tabelle zeigt die Bedeutung der einzelnen Kategorien.
Unter Projekte werden zwei Hauptebenen angezeigt, in denen unterschieden wird, ob Projekte überhaupt Wertebereiche besitzen. Projekte mit Wertebereichen werden detailliert in 4 Kategorien unterschieden.
Projekte mit Wertebereichen Kategorie Bedeutung Automatische Berechnung der Rückwärtssuche: Für die hier aufgelisteten Projekte konnte die Rückwärtssuche automatisch berechnet werden. Eine heuristische Überprüfung hat keine Fehler ergeben.
Unter
$CADENAS_DATA/index/cat/cat_<catalogname>/graphwird eine Dateigraphlookup.maperzeugt. Diese enthält katalogübergreifend alle Informationen bis hinunter auf Projektebene.Manuelle Rückwärtssuche vorhanden (auf Katalogebene gibt es eine Konfigurationsdatei
pnoreverse.cfg)Manuelle Erstellung der Rückwärtssuche notwendig
Alle Projekte, die nicht Kategorie 1-3 zugeordnet werden, erscheinen in Kategorie 4.
Evtl. lässt sich durch gewisse Anpassungen innerhalb der Projektstruktur eine automatische Auflösung doch noch erreichen. Hinweise hierzu finden Sie unter Abschnitt 5.8.2.1.15.29.9, „Reverse Search – Auflösungscheck (automatisch) - Problematische Konstrukte vermeiden“. Ansonsten muss die Rückwärtssuche manuell erstellt werden. Siehe Abschnitt 5.8.2.1.15.31, „Reverse TypeCode Regeleditor“.
Projekte ohne Wertebereiche Eine Aufwandsabschätzung zur Erreichung höchster Suchergebnisqualität ist einfach möglich:
Falls der Katalog nicht vollständig aufgelöst werden konnte, sind Anpassungen für die Projekte unter Kategorie (4) Manuelle Erstellung der Rückwärtssuche notwendig vorzunehmen:
-> Prüfen Sie, ob die betreffenden Projekte durch strukturelle Umstellungen aufgelöst werden können (siehe Abschnitt 5.8.2.1.15.29.9, „Reverse Search – Auflösungscheck (automatisch) - Problematische Konstrukte vermeiden“). Sollte dies nicht möglich sein, müssen manuell Reverse-Konfigs vom Typ
pnoreverse.cfgerstellt werden (siehe Abschnitt 5.8.2.1.15.31, „Reverse TypeCode Regeleditor“).Detaillierte Informationen erhalten Sie durch und Csv exportieren.
Es werden alle Projekte unter Manuelle Erstellung der Rückwärtssuche notwendig exportiert.
Es werden alle gelisteten Projekte exportiert.
IS_COMPLEX: Wahr, wenn es gelbe Felder gibt, d.h. Sachmerkmal oder Geometriemerkmal
1: Projekt enthält Wertebereiche (gelbe Felder) und Automatische Berechnung der Rückwärtssuche geht nicht. -> Es wird eine manuelle Erstellung der Rückwärtssuche benötigt.
2: Projekt enthält Wertebereiche (gelbe Felder) und Automatische Berechnung der Rückwärtssuche geht, sodass diese Projekte automatisch aufgelöst werden können.
-1: Klassifikation nach CNSORDERNO oder CNSTYPECODE fehlt. Vergleiche oben das Icon mit rotem Ausrufezeichen.
-2: Projekt enthält Wertebereiche (gelbe Felder); Auto Reverse Search läuft in einen Timeout. Es werden manuelle Reverse Skripte benötigt.
RANGES: Anzahl Wertebereiche (gelbe Felder). Wenn RANGES=0 ist, dann ist auch SUBTYPE=0)
HASPNO: Zu diesem Projekt ist bereits ein manuell erstelltes Reverse Skript (_pnoreverse.cfg) vorhanden (manuelle Konfigurationslösung).
HASFLAG: Das VARSEARCHRESOLVEORDERNO Flag ist hier schon auf 1 gesetzt und Projekt kommt in Lucenesuche. Muss beachtet werden, um nicht über das Limit von 50000 pro Katalog zu kommen.
REPORT: Detaillierter Report, wie per Algorithmus versucht wird, die Bestellnummer aufzulösen. Feld ist nur ausgefüllt, wenn ein manuelles Skript benötigt wird.
Checken Sie den SVN-Katalog aus (sofern nicht bereits für die Kataloganalyse geschehen).
Aktualisieren Sie den Volltextsuchindex (sofern nicht bereits für die Kataloganalyse geschehen).
Führen Sie den Resolve Check mittels Kontextmenübefehl Reverse Search – Auflösungscheck (automatisch) aus (sofern nicht bereits für die Kataloganalyse geschehen).
Wenn die in den Kategorien (1) Automatische Berechnung der Rückwärtssuche, (2) Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen und (3) Manuelle Rückwärtssuche vorhanden ausgewiesenen Projekte programmintern entsprechend gekennzeichnet werden sollen, klicken Sie unbedingt auf !
Mit Klick auf wird das Auflösungsflag gesteuert.[26]
Bei Projekten in der Kategorie Aufnahme in Volltextindex bis insg. max. 50.000 Zeilen (2) wird das Flag auf 1 gesetzt.
Bei Projekten in der Rubrik Automatische Berechnung der Rückwärtssuche (1) wird das Flag auf 2 gesetzt.
Zeilen ohne Varianten (Wertebereiche) oder mit einer manuellen Resolvekonfiguration (3) bleiben auf 0.
Mit Klick auf bestätigen Sie, dass für die potentiellen x Projekte das Flag gesetzt wird.
Damit die Reverse Search auch tatsächlich zur Verfügung steht, muss das Flag "Auto reverse Search" aktiviert werden.
Optional kann die Reverse search (automatic) für PCOM Portale aktiviert werden.
Ausführen des Befehls Live Stand publizieren... (kostenpflichtig)
Details hierzu finden Sie unter Abschnitt 6.10, „Katalog publizieren“.
Bei neuen oder geänderten Projekten prüft Testmeta, ob die Projekte auflösbar und ob die ORDERNUMBER/TYPECODE klassifiziert sind und gibt Warnungen / Fehler aus.
Was passiert, wenn eine Variable bzw. ein Variablenwert geändert wird?
Für alle Projekte, die über Automatische Berechnung der Rückwärtssuche aufgelöst werden können, sind in diesem Fall bis auf erneute Publizierung des Katalogs keine weiteren Anpassungen nötig.
Was passiert, wenn eine Variable entfällt oder dazukommt?
Für alle Projekte, die über Automatische Berechnung der Rückwärtssuche aufgelöst werden können, sind in diesem Fall bis auf erneute Publizierung des Katalogs keine weiteren Anpassungen nötig.
Wie ist der Ablauf, wenn eine Analyse der Katalogdaten durchgeführt werden soll?
Wenn sich Änderungen ergeben haben, ist die folgende Vorgehensweise für das Katalog-Update durchzuführen:
Aktualisieren Sie den Volltextsuchindex (außer bereits automatisiert geschehen).
Siehe Abschnitt 1.3.8.6.3, „Volltextsuchindex“ in PARTsolutions - Handbuch für Administration.
Ausführen des Befehls Live Stand publizieren... (kostenpflichtig)
In PARTproject -> Projektauswahl -> Kontextmenü des Katalogs (bzw. eines Unterverzeichnisses oder Projekts) -> Automatisierung finden Sie die Funktion Reverse Search – Bestellnummernsuche Testen.[27]
Hiermit haben Sie die Möglichkeit zu prüfen, welche Teile aus einer automatisch erstellten Liste von Bestellnummern bzw. Typenschlüsseln (zusammengesetzt aus Werten gelber Felder) gefunden werden, sodass Sie sicher sein können, dass diese z.B. bei einer Suche im PARTdataManager zu korrekten Treffern führen.
Außerdem können Sie auch eine bestimmte Liste prüfen (entweder initial oder das Outputergebnis der automatischen Generierung nachdem Anpassungen zur Verbesserung der Ergebnisse vorgenommen wurden).
Führen Sie folgende Schritte aus bevor Sie den Testlauf starten:
Stellen Sie sicher, dass Sie den aktuellen SVN-Katalog inklusive der letzten Updates und Änderungen installiert haben.
Stellen Sie sicher, dass ein "frischer" Auflösungscheck durchgeführt wird.
Löschen Sie hierzu unter
$CADENAS_DATA/23dlibs/<catalogname>die Konfigurationsdateiresolvecheck.cfgbevor Sie den Auflösungscheck starten.Fügen Sie den Katalog in PARTadmin in der Konfigurationsdatei
reverselookup.cfg, im Schlüsselgenerategraphein.
Wählen Sie das Katalogverzeichnis, ein Unterverzeichnis oder ein Projekt und klicken Sie auf den Kontextmenübefehl Reverse Search – Bestellnummernsuche Testen.
-> Es wird zunächst eine Liste zufälliger Bestellnummern erzeugt (siehe Fortschrittsbalken unter Erzeugung der Bestellnummern) und im zweiten Schritt werden diese Nummern getestet (siehe Fortschrittsbalken unter Test der Suche).
-> Nach dem Testlauf erhalten Sie die Zusammenfassung der Ergebnisses direkt im Programm.
-> Außerdem werden die Ergebnisse in die automatisch generierte Exportliste geschrieben. Das Testergebnis steht in der letzten Spalte. Gefundene Nummern sind mit "OK" gekennzeichnet, nicht gefundene mit "FAIL".
Wenn es fehlgeschlagene Suchen gab und die Reverse Search Funktionalität optimiert wurde, können Sie mit die Ausgabeliste erneut laden und testen.
Beispiel (initiales Testen einer Liste definierter Bestellnummern/Typecodes)
Alternativ können Sie auch gleich mit einer Liste definierter Bestellnummern/Typecodes testen. Die Einstellung unter Anzahl pro Projekt ist dann nicht relevant.
Starten Sie den Prozess mit Klick auf .
-> Das unter Zielpfad Exportliste eingestellte Verzeichnis wird geöffnet. Wählen Sie die gewünschte CSV-Datei.
-> Die Funktion wird ausgeführt und die Ergebnisse werden in die geladene CSV-Datei geschrieben.
Das Testergebnis steht in der letzten Spalte. Gefundene Nummern sind mit "OK" markiert, nicht gefundene mit "FAIL".
Bestellnummern testen via "Reversemap Service"
Wenn die Reverse Search bereits für die Online Verwendung aktiviert wurde, können Sie Bestellnummern manuell mit dem "Reversemap Service" testen.
Geben Sie einfach die URL im Browser ein und sehen Sie, ob Sie den MIdent zurückbekommen.
https://webapi.qa.partcommunity.com/service/reversemap?catalog=norelem&part=06247-116044&exact=1
https://webapi.partcommunity.com/service/reversemap?catalog=norelem&part=06247-116044&exact=1
catalog = -> Katalog in dem gesucht werden soll
part = -> Bestellnummer nach der gesucht werden soll
exact = -> 1 (Exakte Suche nach der Bestellnummer); 0 (Groß-/Kleinschreibung ignorieren)
Bestellnummern testen auf 3Dfindit oder Supplier Portal
Sie können auch auf dem 3Dfindit- oder einem Supplier-Portal nach Bestellnummern suchen (entsprechender Config-Key muss zuvor auf dem Supplier-Portal aktiviert worden sein.
Stellen Sie sicher, dass Sie den Katalog auf 3Dfindit bereits selektiert haben. In der Standard-Suchleiste von 3Dfindit funktioniert die Bestellnummernsuche nicht.
Bei der automatischen Berechnung der Rückwärtssuche wird unter
$CADENAS_DATA\index\cat\cat_resolve_check\grapheine Dateigraphlookup.maperzeugt. Diese Datei wird beim Upload auf Online-Portale standardmäßig ignoriert und muss zur Verwendung explizit von CADENAS freigeschaltet werden.Die Suche nach Bestellnummer oder Typbezeichnung funktioniert auf Online-Portalen nur im betreffenden Katalog (in PARTdataManager auch über alle Kataloge).
Sinnvollerweise wird man eine Suche immer im gewünschten Katalog durchführen. Manchmal besteht ein Katalog aber aus Unterkatalogen (der Normenkatalog beispielsweise aus DIN, ISO, EN, etc.). In einem solchen Fall führen Sie die Suche bitte im betreffenden Unterkatalog aus.
Beim Erstellen der CIP-Datei des Katalogs werden in der
dir.prjdes Katalogs die Ergebnisse des Auflösungscheck in Form folgender Schlüssel gesetzt:CATMETRICS_SEARCHABLE_PROJECTS
Anzahl von Projekten, die gefunden werden sollten (alle sichtbaren Projekte und Projekte mit SEARCHINDEX=ON)
Anzahl von Projekten mit einer klassifizierten Bestellnummer oder Typecode Variable
Anzahl von Projekten mit Bestellnummern und Typecodes, die über Lucene indexiert sind.
Anzahl von Projekten mit automatischer Berechnung der Rückwärtssuche
Anzahl von Projekten, die nicht mit der Reverse Search gefunden werden können
Hintergrundinformation: Um die Informationen zu erstellen, die in die
dir.prjgeschrieben werden, werden die Konfigurationsdateienresolve_check.cfgundqacheck.cfgausgewertet. Inresolve_check.cfgschreibt z.B. der ResolveChecker, für welche Projekte eine automatische Reverse Search möglich ist. Es kann aber sein, dass jemand ein Projekt geändert hat, ohne den ResolveChecker auszuführen. In diesem Fall wird die Information aus derqacheck.cfggelesen, in welche Testmeta schreibt, und Testmeta muss auf jeden Fall für geänderte Projekte aufgerufen werden, da sie ansonsten nicht publiziert werden können.
Die
Konfigurationsdatei findet sich unter $CADENAS\libs\all\plugins\resolve_check.cfg:
Die Qualität der heuristischen Überprüfung bei der automatischen Berechnung der Rückwärtssuche kann mittels der ersten drei Schlüssel eingestellt werden.
Wird NEVERSKIPGRAPH auf 1 gesetzt (Default ist 0), wird bei jedem Lauf eine komplette Neuberechnung durchgeführt. (Zu Testzwecken evtl. sinnvoll, wenn die automatische Generierung verbessert wurde.)
[COMMON] # maximum graphsearch searches per project MAXHEURISTICS=10000 # maximum time in minutes to use when counting variants MAXTIME=15 # maximum time in minutes when checking graphsearch results MAXTIMETEST=15 # always recheck the graphsearch even if we already have a saved result NEVERSKIPGRAPH=0
Definitionen für verwendete Variablenabkürzungen
Die folgende Abbildung zeigt den Einstellungsbereich für oben erwähnte Wertebereichsvariaben.
Beispiel 1 - Indirekte, berechnete Verwendung des Wertebereichs
Hinweis Bei der Verwendung von Algorithmen gilt folgende Einschränkung:
Ein Algorithmus ergibt "vorwärts" immer einen konkreten berechneten Wert, aber "rückwärts" kann der im Algorithmus verwendete Wert nicht erschlossen werden, wenn eine arithmetische Operation verwendet wird; direkte Substitution hingegen funktioniert.
Die Bestellnummer (NR) resultiert aus dem String 'xyz' und einem Merkmalalgorithmus.
NR=xyz ALG ALG=10*RNG
Problem: ALG kann einem eindeutigen Wert zugeordnet werden, aber aufgrund oben genannter Einschränkung kann der Wert von RNG nicht ermittelt werden.
Gleiches würde auch für folgende leicht abgewandelte Fälle gelten, da auch hier eine arithmetische Operation durchgeführt wird:
Eine Lösung könnte evtl. darin bestehen, die Wertebereichswerte so zu bestimmen, dass eine Berechnung mittels ALG unterbleiben kann und direkt RNG zur Bestimmung von NR verwendet wird.
Beispiel 2 - Vorwärts-Auflösung mit Algorithmen
ALG1: Vorwärts zu einem Wertebereich
ALG1=RNG (ALG1 fußt auf einem Wertebereich)
ALG2: IF Statement zur Bestimmung des angezeigten Bestellnummerwertes
If ALG1='xyz' then ALG2=123 Else If ALG1='abc' then ALG2=789 End if NR=DIN ALG2
ALG1 kann einem eindeutigen Wert zugeordnet werden, aber aufgrund oben genannter Einschränkung kann der Wert nicht gesetzt werden.
Verwenden Sie im IF-Statement direkt den Wertebereich anstatt der Algorithmus-Variablen.
If RNG='xyz' then ALG2=123 Else If RNG='abc' then ALG2=789 End if NR=DIN ALG2
Beispiel 3 - Kein Trenner zwischen Wertebereichsvariablen
NR=RNG1RNG2
Es gibt keinen Trenner zwischen den zwei Wertebereichen, so dass nicht klar ist, aus welchen Einzelwerten Bestellnummer/Typecode (NR) zusammengesetzt wurde.
NR='3412' könnte eine z.B. eine Kombination aus '341' und '2' sein oder aus '34' und '12'.
Lösung: Setzen Sie einen Trenner zwischen die Wertebereichsvariablen, dann ist klar, welches Element zur Wertebereichsvariablen 1 und welches zur Wertebereichsvariablen 2 gehört.
NR=RNG1-RNG2Beispiel 4 - Keine eindeutigen Pfade mit gleichem Ergebnis
If a=1 then ALG='01' Else if a=2 then ALG='0$RNG.' End if
ALG hat mehrere Optionen, die teilweise gleich sind. In der ersten Bedingung "01" und in der zweiten Bedingung "01".
Wenn ALG denselben Wert annimmt, kann die Rückauflösung nicht gelingen. Es kann nicht entschieden werden, ob der Fall "a=1" oder "a=2" vorliegt. Damit ist dann sekundär auch eine Aussage über RNG=1 falsch.
[26] Schlüssel VARSEARCHRESOLVEORDERNO.
Auf Projektebene steht dieser in der Projektdatei, auf
Katalogebene in $CADENAS_DATA/23d-libs/<katalogname>/dir.prj.
Keine GUI-Entsprechung. Manuelles Eingreifen ist nicht
nötig.
[27] Die entsprechenden Plugin-Dateien müssen unter %CADENAS%/libs/all/plugins liegen: resolve_check_tester.cfg, resolve_check_tester.def, resolve_check_tester.vbb