Mehrwertiges Feld im Bericht

[DF6GL]

Hallo,

Ich habe doch die Schüler in einer Tabelle (tbl_SCHUELER), in einer anderen Tabelle habe ich die sonderpädagogischen Maßnahmen (tbl_SONDERPAEDAGOGIK) und beide treffen sich in der m:n-Tabelle tbl_BEARBEITUNG_SCH_VER.

Das ist ja ok und ganz normaler Standard. Hat aber mit SOP_MFS  nichts zu tun.

Nun werden in dieser m:n-Tabelle auch in korrekter Weise die Mehrfachbehinderungen im Feld SOP_MFS gespeichert, nämlich 'GBP', 'KBP' für eine zweifache Behinderung wie eine 'Geistige Behinderung' und eine 'Lernbehinderung'.

Woher kommen denn die Benennungen für die Mehrfachbehinderung ('GBP', 'KBP' )? In welcher Tabelle stehen die?


Möglicherweise:

Die Stammdaten-Tabelle zu den Behinderungsarten heißt tbl_SONDERPAEDAGOGIK

Warum heißt die nicht sinnvollerweise tbl_Behinderungsarten?



Ich gehe dabei vom ursprünglichen Problem aus:

im Bericht selbst werden aber die ID-Nummern der Behinderungsarten [1;2;...]

Wenn beim Erstellen des Mehrwertfeldes keine externe Tabelle angegeben wurde, aus der die Daten kommen sollen, sondern nur die Text-Daten in die Liste direkt eingetragen wurden, dann sollten im Bericht keine Zahlen (Fremdschlüsselwerte) auftauchen.

Eigentlich habe ich in der m:n-Tabelle 'tbl_BEARBEITUNG_SCH_VER' das Fremdschlüsselfeld SOP_FS durch ein mehrwertiges Feld SOP_MFS ergänzt

Welchen Steuerelementinhalt hat das  Feld SOP_MFS ?
Sorry , ist quatsch an dieser Stelle...

Code [Auswählen] Erweitern

Ich habe gar keine Idee, warum ich das Feld SOP_MFS.Value in eine Relation setzen soll


Setz das mal mit tbl_SonderPaedagogik.SOP_PS  in Relation.

Zudem solltest Du noch versuchen, im Beziehungsfenster ALLE Tabellen anzuzeigen.

[gromax]

Hallo Franz,

Du machst Dir richtig Mühe - vielen Dank dafür!

Folgend versuche ich die aufgeworfenen Fragen zu beantworten:
1. Die Benennungen kommen aus der Tabelle tbl_SONDERPAEDAGOGIK [3 Felder mit Feldnamen: SOP_PS - SOP_Feststellung (lang) - SOP_Feststellung (kurz)]
2. Die Benennung dieser Tabelle habe ich nach den Sonder- und Förderschularten und den dabei hinterlegten Studienrichtungen gewählt; tbl_BEHINDERUNGSARTEN wäre genauso möglich gewesen.
3. Die externe Tabelle des mehrwertigen Feldes, das in der m:n-Tabelle tbl_BEARBEITUNG_SCH_VER eingepflegt wurde, ist die Tabelle tbl_SONDERPAEDAGOGIK  ("Datensatzherkunft").
4. Das ist spannend; das muss ich noch ausprobieren, nicht wissend, in welcher Weise dies auf meine Berichte durchschlägt. Aber dieser Spur gehe ich noch nach!
5. Das Fremdschlüsselfeld SOP_MFS hat sich selbst als Steuereleméntinhalt.
6. Das habe ich schon probiert; das ändert nichts an der Diskrepanz der Darstellung in der Tabelle und Abfrage zu der im Bericht.

Ich tüftle gerade an einem Ansatz, den Du vielleicht noch bewerten könntest:
Kann man denn die korrekte Darstellung in der Tabelle oder in der Abfrage nicht mittels eines Ereignis-Codes per VBA in den Bericht übernehmen? Meine Versuche dazu hatten allerdings noch keine brauchbaren Ergebnisse, aber das ist auch meiner fehlenden VBA-Kompetenz zuzuschreiben.

Viele Grüße an den Bodensee
gromax

[DF6GL]

Hi,

6)

Damit meinte ich implizit auch das (nochmalige) Hinzufügen der Pädagogik-Tabelle und ziehen einer Verknüpfungslinie im Abfrageentwurf.

[gromax]

Hallo Franz.

das funktioniert nicht; ich erhalte dann die Meldung: "Die Eigenschaftseinstellung kann nicht größer als 2 KB sein!"
Was immer das bedeutet?

Viele Grüße
gromax

[DF6GL]

Hallo,

kannst Du die DB (gezippt und komprimiert/repariert) hier hochladen?

[MaggieMay]

Hi,

sofern es immer noch um das Datenfeld SOP-MFS geht, so zeige doch bitte einfach mal was bei den Eigenschaften im Register "Nachschlagen" im Tabellenentwurf dort zu sehen ist.

PS:
Der Screenshot vom Beziehungsfenster ist insofern untauglich, dass die Linien sich teilweise überlagern und die Berziehungen somit nicht eindeutig erkannt werden können.
Offensichtlich ist allerdings, dass es keine Beziehung zum Datenfeld SOP_MFS.Value gibt, was ja bereits bemerkt wurde, wodurch sich bzgl. der notwendigen Erweiterung der Abfrage für uns nichts ableiten lässt.

[gromax]

Hallo Franz, hallo MaggieMay,

gerne sende ich Dir meine DB; alle Daten sind fiktive Daten. Es gibt das Schulamt nicht, ebenso sind die Schulen und auch die Schüler der Phantasie entsprungen.
Zum Vorgang:
Mit dem Formular "frm_AuswahlRptEinzeln" werden die Berichte zu den Schülern aufgerufen; wähle den Bericht zum erstgenannten Schüler "Aach, Alfons" aus und Du erkennst die beiden ID-Nummern zu den Behinderungsarten in diesem Bericht.
Im Bericht "rpt_SCHUELER_Einzeln" sollten die Kurzbezeichnungen aufgeführt werden gleich wie in der m:n-Tabelle "tbl_BEARBEITUNG_SCH_VER" bzw. in der Abfrage "qry_BEARBEITUNG_SCH_VER_EIN_Bericht_Alle".
Die Eingaben werden im BEARBEITUNGS-Dialog "frm_SCHUELER03" vorgenommen.
Ich bin gespannt und freue mich!

Viele Grüße
gromax

[DF6GL]

Guten Morgen,

ändere das Textfeld "SOP_Feststellung (kurz)"  im Bericht in ein Kombifeld mit den gleichen Einstellungen wie das Nachschlagefeld in der Tabelle "tbl_BEARBEITUNG_SCH_VER" ...

[gromax]

Hallo Franz,

ich bin begeistert! Das klappt bestens.

Vielen Dank und morgen einen guten Start in die Woche!

Viele Grüße an den Bodensee
gromax

[MaggieMay]

Hallo,

ich halte die Lösung für keine so gute Idee, weil Kombifelder in Berichten eigentlich nichts zu suchen haben - muss aber feststellen, dass hiermit die gewünschte Funktionalität erreicht wird.

Allerdings...
Bei Ansicht der Tabelle "tbl_BEARBEITUNG_SCH_VER" fällt auf, dass sowohl "SOP_FS" als auch "SOP_MFS" in unkoordinierter Weise an die Tabelle "tbl_SONDERPAEDAGOGIK" gebunden sind.
Hier gibt es also erstmal noch Klärungsbedarf...

[DF6GL]

Hallo,

das eigentliche Problem liegt an der gruppierenden Berichtsabfrage...

Ansonsten halte ich (auch) von diesen Mehrwertfeldern gar nichts, die Verkomplizieren die Sachlage unnötig und "versauen" die Transparenz der DB.

Weitere Info:

https://support.office.com/de-ch/article/Verwenden-von-mehrwertigen-Feldern-in-Abfragen-6f64f92d-659f-411c-9503-b6624e1e323a


Auf die Doppelbeziehung der besagten Tabelle will ich jetzt nicht eingehen...