Moin allerseits (auch wenn es schon wieder spät ist)! 
Für einen Nachbarschaftshilfe-Verein möchte ich ein Auftragsformular zusammenstellen, in dem die Helferauswahl per Kategorientabelle gesucht bzw. gefiltert wird. Damit die Helferkategorien erweitert werden können, ohne dass das Formularlayout geändert werden muss, wäre eine Formulartabelle mit der Kategorienauswahl in Markierfeldern gewünscht (siehe Bild unten). Das ginge sicher auch per Mehrfachauswahl in einem Listenfeld aber Markierfelder erscheinen mir intuitiver für unbedarfte Anwender.
Nun stoße ich dabei auf mehrere Probleme: Die Markierfelder werden überhaupt erst sichtbar, wenn die Formulardaten zumindest als änderbar markiert sind. Das Anklicken einer Kategorie soll aber keine Aktion in der DB auslösen sondern nur das Filterkriterium zusammenstellen. Damit stellt sich mir eine grundsätzliche Frage: Sind in einem Base-Formular auf Basis einer DB-Tabelle überhaupt Felder möglich, die von der DB “abgekoppelt” sind? (Ich kenne das von Oracle-Forms und bin übrigens beeindruckt, wie viel ich davon in LO-Base wiederfinde! Auch die Doku. und Handbuch sind wunderbare Einstiegshilfen! 
)
Erstmal: Was Du auf einem Formular eingibst landet nicht direkt in der Datenbank, sondern erst mit einem Commit() oder Save wird der Inhalt des Datensatzes in die Datenbank geschrieben. (Daher findet man gelegentlich Macro-Lösungen, die einen Commit/Refresh auslosen, wenn sich Felder ändern. In anderen Fallen wird z.B. ein Refresh-Button zusatzlich erstellt.)
Habe ich nie probiert. Ich schatze dass das geht, aber abgekoppelt bedeutet dann auch: Deine Auswahl ist der Datenbank nicht bekannt. Du musst die Felder dann per Macro auslesen…
.
Was ich (wie viele andere) nutze sind Filtertabellen. Ein Formular kan nämlich auch den Inhalt mehrerer Tabellen/Abfragen gleichzeitig darstellen, also auch Filtertabelle und Datentabelle. Damit kennt die Datenbank (nach commit) den Inhalt des Filters und eine Abfrage kann direkt auf die Daten zugreifen.
Alle Felder sind auch ohne direkte Anbindung an eine Datenquelle nutzbar. Markierfelder kann ich ohne Bezug zu einem Formularfeld in jedes Formular packen. Um die Auswertung muss ich mich dann allerdings selbst bemühen - also Makros.
Ich habe einmal so etwas zusammengestellt um innerhalb von einem Formularfeld alle möglichen Eigenschaften zu speichern. Das läuft dann nach einer internen Wertezuweisung (1,2,4,8,16…) und wird dann addiert als Wert ins Formular geschrieben. Habe ich auch ins Handbuch übertragen: Kapitel Datenbank-Aufgaben → Codeschnipsel → Mehrere Werte in einem Feld speichern.
Vermutlich ist das die einfachste Lösung in LO-Base auch wenn sie mir nicht gefällt: Was hat das Filter in der DB zu suchen? Unnötiger Netzwerk-Roundtrip, unnötige Transaktion, muss multi-user-tauglich gemacht werden (eigentlich session-spezifisch). Wenn Filtereinstellungen eine Session überdauern sollten, sähe die Sache natürlich ganz anders aus.
Ganau das gelingt mir nicht. Entweder habe ich noch eine Verständnislücke oder die Abkopplung eines Markierfelds von der DB innerhalb eines Tabellenformulars ist nicht möglich.
Grundlage für das Tabellenformular wäre z.B.:
select "ID", "Standardaufgabe", 0 as "Auswahl" from "Standardaufgaben";
- Wenn ich in Eigenschaften: Markierfeld → Daten → Datenfeld leer lasse (oder irgendeinen neuen Namen eintrage), wird das Markierfeld zur Laufzeit unsichtbar!?!
- Sobald die Formulartabelle als änderbar gekennzeichnet ist, lösen verschiedene Navigationsaktionen eine Transaktion aus, nachdem ein Markierungsfeld geändert wurde. Kann man diese Transaktionen in Ereignissen evtl. unterbinden? (à la “instead-of-trigger”)
Ich habe in dem Screenshot gar nicht das Tabellenkontrollfeld gesehen (arbeite grundsätzlich nicht mit irgendwelchen Dark Themes). In dem geht das in der Tat nicht, da die Felder dann nicht sichtbar sind. Da bliebe nur, die jeweilige Auswahl erst einmal zu speichern, dann der Person zuzuordnen und schließlich das Feld wieder auf “False” zu setzen.
Ich arbeite hier übringens auch beständig mit den Filter-Tabellen - auch im Serverbetrieb. Bei Firebird mache ich die Filterung von CURRENT_CONNECTION abhängig. Beim Schließen der Base-Datei lösche ich dann die entsprechende Zeile aus der Filtertabelle. Und zur Filterung selbst nutze ich dann eine Ansicht, die nur die Daten für die CURRENT_CONNECTION darstellt.
Vermutlich ist das die einfachste Lösung in LO-Base auch wenn sie mir nicht gefällt: Was hat das Filter in der DB zu suchen? Unnötiger Netzwerk-Roundtrip, unnötige Transaktion, muss multi-user-tauglich gemacht werden (eigentlich session-spezifisch). Wenn Filtereinstellungen eine Session überdauern sollten, sähe die Sache natürlich ganz anders aus.
Ich verstehe das Problem nicht. Ist es nicht sinnvoll, die Filtertabelle ohnehin in der DB zu halten, damit alle USER auf die gleichen “dynamischen” Werte zurückgreifen? Oder möchtest du die Kriterien bei Erweiterung/Kürzung auf jedem Client einzeln anpassen?
Anbei ein einfaches Beispiel alà Robert.
Dynamische_Filtertabelle.odb (15.3 KB)
Die Filtertabelle (Hilfskategorien/Standardaufgaben) sollte auf jeden Fall in die DB aber nicht die Filtereinstellung also die konkrete Auswahl (Spalte “Helferfilter”), denn diese ist für jede Suche nach einem passenden Helfer bei der “Auftragsvergabe” anders gesetzt. Möglicherweise gibt es aber bei den “Disponenten” eine Aufgabenteilung, so dass z.B. ein bestimmter Anwender immer Fahrdienste organisiert. In diesem Fall wären (nutzerspezifische) Voreinstellungen der Filter natürlich ganz nützlich.
Danke für die Beispiel-odb! Genau so, mit dem gleichen Subselect, habe ich es aktuell auch implementiert (mit dem befürchteten Ergebnis: holprige GUI-Reaktion bei der Filterauswahl. Manchmal muss ich das Markierfeld zweimal anklicken bevor es reagiert. Mal sehen, wie das erst mit einer remote-DB läuft, aktuell teste ich mit der embedded HSQLDB.)
Nochmals vielen Dank für eure Kommentare!
Bei mir holpert da garnix, und ich muss auch nur einmal klicken.
Ich habe eine Filtertabelle mit user und numerischer ID als Primärschlüssel. Funktioniert super.
CREATE TABLE "FLT"("D1" DATE,"D2" DATE,"INT1" INTEGER,"INT2" INTEGER, "INT3" INTEGER, "DEC1" DECIMAL(7,2),"DEC2" DECIMAL(7,2), "C1" VARCHAR(50), "C2" VARCHAR(50), "C3" VARCHAR(50),"BOOL1" BOOLEAN, "BOOL2" BOOLEAN, "DESCR" VARCHAR(200),
"FID" SMALLINT NOT NULL,
"USR" VARCHAR(12) NOT NULL,
PRIMARY KEY("FID","USR"));
Das sind diverse Felder für häufig benutzte Filterkriterien, ein Feld “DESCR” für Beschreibungen der Filter und einen zusammengesetzten Index, wo jedes Kriterien-Set “FID” für jeden angemeldeten Benutzer angelegt wird. Bei einer kleinen Arbeitsgruppe durchaus manuell administrierbar.