Hallo Benny,
ja, jetzt versteh ich das eigentliche Problem.
Lösungsansätze könnten sein:
Anstelle einer FS_DATASET Eingabekomponente eine CMS_INPUT_COMBOBOX (mit CMS_INLUDE_OPTIONS) nehmen. Deren VALUE müsste eine Zahl (Long oder Integer, abhängig von Spaltenkonfiguration in der Datenbank) sein, die man dann einfach per Regel auf eine CMS_INPUT_NUMBER umbiegen kann. Nachteile: bereits gepflegte Daten sind nicht kompatibel, Eingabekomponente ist schlechter zu handhaben für die Nutzer.
In der contentSelect Funktion mittels LIKE die Persistenz der FS_DATASET Eingabekomponente abfragen. Da diese auf eine externe Tabelle zeigt, müsste da so etwas wie <KEY><ITEM>#ID</ITEM></KEY> drin stehen, wobei #ID die ID des Datensatzes aus der externen Tabelle ist. Da müsstest Du dann mal probieren, wie man den CMS_VALUE_PARAM sauber zusammensetzen muss. Entweder "> + #row.Id + <" oder "\> + #row.Id + \<" oder evtl. auch den String erst im Template zusammensetzen und dann die contentSelect Funktion in einer Formatvorlage nutzen (Konfiguration und Ausgabe), der der zusammengesetzte Parameter übergeben wird. {einfacher wäre es, wenn die ID eindeutig ist - also alle IDs dieselbe Anzahl an Stellen haben. Also ausgeschlossen ist, dass eine ID eine Teilmenge einer anderen ID ist. Halte ich aber für nicht realistisch} Nachteile: Ziemliches "Gefummel" um die Daten sauber abfragen zu können, LIKE Statements sind weniger performant
Einen eigenen VALUE Service schreiben, der die FS_DATASET Eingabekomponente ausliest, daraus die ID extrahiert und diese in die andere Eingabekomponente schreibt. Wenn man den an den Focus der FS_DATASET Eingabekomponente knüpft und den Wert der anderen Eingabekomponente nur ändert, wenn diese den Wert noch nicht hat, sollte das sauber funktionieren.
Ein Skript/Modul schreiben, welches den Identifier in eine versteckte Eingabekomponente schreibt. Dieses vor jeder Generierung ausführen. Wenn man sich für diese Lösung entscheidet, sollte sichergestellt werden, dass die versteckte Eingabekomponente nicht jedes mal neu geschrieben wird. Beispielsweise kann diese per Regel bei jedem manuellen Bearbeiten (onlock) geleert werden. Dann braucht sie nur neu gesetzt zu werden, wenn sie nicht gesetzt ist. Nachteile: wieder "Gefummel", um das sauber und performant hinzubekommen. Funktioniert in der Vorschau der externen Datensätze erst nach der nächsten Generierung (warum, weiß in zwei Monaten niemand mehr 😉
Ich hoffe, dass hilft irgendwie weiter 🙂
Holger