Hallo,
ich versuche gerade, einen Katalog (vorgegeben von unserem Hersteller) einzubinden. Das Format ist also vorgegeben und nicht änderbar…
Zur Identifikation eines Produktes möchte ich ein Kaskade von relationalen Verknüpfungen (Typ->Modell->Version) erstellen, wobei nach Eingabe in eines der Eingabefelder
a) das Feld eine Ebene zur Bearbeitung freigegeben wird (das geht einfach über die Bedingungen zur Sichtbarkeit/Bearbeitung)
b) und in diesem Feld nur Einträge zur Auswahl angeboten werden, die zur Auswahl eine Ebene höher passen (wenn also ein Typ ausgewählt wurde, sollen in der nächsten Auswahl nur die zugehörigen Modelle angeboten werden, sobald das Modell ausgewählt wurde nur die Versionen, die zum Modell gehören).
Ich habe momentan gar keine Ahnung, wie ich den Effekt realisieren kann.
Lassen sich eventuell Filter dynamisch belegen?
Vielen Dank im Voraus für jede Hilfestellung
Wolfgang
Wir haben exakt so etwas in der Ansicht „Firmen“ für die Auswahl der Branche2 realisiert. Dort werden nur „Unter-Branchen“ angeboten, die zur gerade ausgewählten Branche1 „passen“:
Die im Formel-Assistent angebotenen Felder entsprechen dem top-aktuellen Inhalt des Feldes in der Eingabemaske, auch wenn er gerade von der:dem Anwender:in verändert und noch nicht gespeichert wurde.
Grundsätzlich hat @beggstein Recht, es ließe sich außerdem auch mit einem SQL Filter lösen.
Die Frage ist aber erstmal in welcher Form die Daten aus dem Quellsystem vorliegen. Gibt es Tabellen für Typ->Modell->Version mit Fremdschlüssel untereinander oder ist das eine hierachische Tabelle die auf sich selbst referenziert?
Ich habe das Problem mittels desvon @beggstein beschriebenen Verfahrens lösen können. Insofern habe ich eine funktionierende Lösung (und wir brauchen auf das Thema keine Zeit mehr zu investieren).
Trotzdem bin ich natürlich neugierig auf einen SQL-basierten Ansatz, bei meinen Datenmengen könnte der nämlich deutlich schneller sein!
Ich habe Tabellen, die mit Fremdschlüssel untereinander verbunden sind
Ich will ja nicht kleinlich sein , nur der von mir skizzierte Ansatz IST ein SQL basierter Ansatz. Es werden per SQL Abfrage (jeder Filter und jede Suche in der combit CRM Oberfläche ist eine SQL Abfrage) nur alle Einträge angeboten, die dem Kriterium entsprechen. Im vorliegenden Fall ist das Vergleichskriterium für die Abfrage der aktuelle Wert aus einem anderen Eingabeelement. Anders geht es auch nicht, da das Kriterium ja gerade eben überhaupt erst ausgewählt/eingestellt und noch gar nicht gespeichert wurde. D.h. eine gerade ausgewählte Branche1 führt zu einer dazu passenden eingeschränkten Branche2 Unterauswahl - noch während der Datensatz ungespeichert in Bearbeitung ist.
Jetzt bin ich natürlich auch auf den alternativen Ansatz gespannt.
Ich habe hier nun noch ein weiteres Problem:
In meiner Hierarchie Typ->Version->Modell gibt es zu jedem Modell Optionen (1:N), ich kann also zu jedem Modell 0…n Zusatzoptionen eintragen, die wieder von Typ, Version und Modell abhängig sind (die drei Codes lassen sich also als Filter verwenden).
Kann ich bei der Neuerstellung eines Eintrags in einen Container die drei Werte gleich standardmäßig vorbelegen, so dass dann in der Optionsansicht ein Filter analog zu den im Thread bereits beschriebenen aktiviert werden kann?
Oder macht man so etwas ganz anders?
Sie bringen jetzt den Begriff „Container“ ins Spiel. Was meinen Sie genau damit? Bislang spielte sich die Party komplett in 2 Feldern einer Ansicht ab in Kombi mit jeweils einer Auswahlschaltfläche eines relationalen Datensatzes dafür. Ohne weitere Mittänzer. Inwiefern kommt jetzt ein Container ins Spiel und wo sind dabei die 2 (jetzt 3) Felder?
Der Container kommt von einer 1:N-Verknüpfung,an die ich beim ersten Stellen der Frage noch gar nicht gedacht habe.
Es ist in der Tat so, dass dieser Katalog über Typ-Modell-Version je in einer 1:1-Beziehung ein Fahrzeg spezifiziert, dem Fahrzeug aber (in Abhängigkeit von Typ-Modell-Version) zusätzliche Option(en!) hinzugefügt werden können. Eine klassische 1:N-Beziehung. Die würde ich beim cRM doch mittels Container realisieren?
Das Datenmodell gibt es her, dass Typ, Modell und Version mit jeder Option gespeichert werden. In der Optionsansicht lässt sich also der Filter auf erlaubte Optionen setzen, wie in der ursprünglichen Problemlösung. WENN ich die drei Felder in der Optionsansich korrekt vorbelegt bekomme.
Wenn Sie bei den „Optionen“ auch eine 1:1 „Rückrelation“ zur 1:N „Hin“-Relation definieren, so dass man von der „Option“ eben auch umgekehrt direkt zum übergeordneten „Fahrzeug“ kommt (das die Optionen ja in seinem 1:N Container besitzt), dann können Sie direkt in dem Filter, der die Datensatzauswahlmöglichkeiten einschränkt (siehe oben bzgl. Branche1 und Branche2), auf die Felder des übergeordneten Datensatzes zugreifen und als Vergleichswert eintragen.
Sie müssen also nicht 3 Felder „vorbelegen“, sondern Sie greifen direkt auf die 3 Felder mit ihren aktuellen Werte des übergeordneten Datensatzes zu.
Hier ein Screenshot zur Verdeutlichung. In diesem (hier jetzt völlig sinnlosen, aber egal) Datensatzauswahlfilter in der Ansicht Belegposten kann ich (analog zum Branchen2-Beispiel) die Auswahl der angebotenen was-auch-immer-ich-hierauswähle Datensätze einschränken und dabei bei der Vergleichswert-Formel auf alle Felder des mit dem Posten 1:1 verknüpften „übergeordneten“ Beleges direkt zugreifen:
Beleg = Fahrzeug mit seinen 3 „es bestimmenden“ Feldern
Belegposten = Option, die 1:N unter dem Fahrzeug hängt.
Wenn ich mich verworren ausdrücke, einfach nochmal melden.
Der Vorteil gegenüber dem Umkopieren der 3 Felder in jede Option ist, dass Sie redundante Daten vermeiden. Jede Option wird ja immer exakt dieselben 3 Werte enthalten, sie gehören ja nämlich „eigentlich“ zum die Option besitzenden Fahrzeug (ist das Deutsch? ).
Wenn Sie auf dem Umkopieren bestehen , dann bitte melden, das geht recht einfach.
Und zum Thema 1:n-Beziehungen anlegen sei noch ergänzt:
Um einen Datensatz im Container anlegen zu können muss der aktuelle Datensatz gespeichert sein. Damit lassen sich dann natürlich alle Filter auch als SQL Filter erstellen, sofern die Relationen sauber aufgebaut wurden.
Die „SQL-Version“ bezog sich jetzt in diesem Fall auch erstmal auf einen (SQL) Filter, der in der Eingabemaske auch gewählt werden kann. Auch hier gilt natürlich die Einschränkung das nur die Eingabemaske weiß, welche Information ausgefüllt wurde aber noch nicht in der DB gespeichert wurde. Daher käme mir jetzt auch keine andere elegante Lösung in den Sinn.
Der Filter würde dann mit [dbo].cmbt_fct_FormatGUID arbeiten, wobei spalte dem Feld entspricht, das in der Maske gesetzt wurde und nach dem in der DB gesucht werden soll.
, nur der von mir skizzierte Ansatz IST ein SQL basierter Ansatz. 
Es werden per SQL Abfrage (jeder Filter und jede Suche in der combit CRM Oberfläche ist eine SQL Abfrage) nur alle Einträge angeboten, die dem Kriterium entsprechen. Im vorliegenden Fall ist das Vergleichskriterium für die Abfrage der aktuelle Wert aus einem anderen Eingabeelement. Anders geht es auch nicht, da das Kriterium ja gerade eben überhaupt erst ausgewählt/eingestellt und noch gar nicht gespeichert wurde. D.h. eine gerade ausgewählte Branche1 führt zu einer dazu passenden eingeschränkten Branche2 Unterauswahl - noch während der Datensatz ungespeichert in Bearbeitung ist.
).