Office: (Office 2016) vorhandenes Formular dynamisch mit allen Feldern der akt. Datensatzquelle füllen

Hallo Pavel,

anbei eine kleines Beispiel, angepaßt für ein Sub-Formular in der Datenblattansicht. Bei einem "normalen" Formular würde man Application.Screen.ActiveDatasheet abfragen.

Gruß Ulrich

 

Hallo Pavel,
kann man von Dir ein Bild Deines Beziehungsfenster bekommen, bitte?
Ich arbeite gerade an einer Klassenarbeits-Access DB und würde mich freuen, wenn Du mir helfen würdest, indem Du mein Tabellenmodell kommentierst.
https://www.ms-office-forum.net/foru...27#post1937127
Es sind natürlich auch alle anderen eingeladen. Ich will aber nicht aufdringlich wirken.

 

\@ebs17, die Körperverletzung tut mir Leid. Die verpixelten Flächen sind aber Absicht. Das sind die Namen meiner Schüler Ich bin da etwas penibel beim Datenschutz. Bei 100KB Limit für Bilder kann man aber auch keine Wunder erwarten. Es ging mir nur um die Aufteilung des Formulars und eine grobe Idee der Funktion.

@markusxy, danke Dir!!! Probiere ich aus, wenn ich hier ne Weile Ruhe hab. Danke noch mal für die Mühe!

 

\@Ulrich, danke!!!
Ihr seid klasse! Komme wahrscheinlich erst heute Nacht dazu aber ich bin mir jetzt schon sicher, dass mich das weiterbringt.

 

Hallo,

das ist das eigentliche Dilemma an der Geschichte.
Das wäre ein typischer Fall einer n:m Beziehung zur Erfassung der Notizen zum Beobachtungsschwerpunkt. Dann würde diese ganze Dynamik ersatzlos entfallen.

Wenn durch neue Daten Tabellenspalten hinzugefügt werden müssen, hat man ein falsches Datenmodell angelegt.
Dass der Tabellenaufbau falsch ist, kann man auch an den 4 Feldern für Betragen, Mitarbeit, Fleiß und Ordnung erkennen.

Ein Bild der Beziehungen würde mich auch mal interessieren.

 

Hallo Pavel,
noch ein Hinweis auf eine Seite, die eventuell für dein Vorhaben von Nutzen sein könnte (wobei es mehr um das Prinzip als solches geht):
https://team-moeller.de/?Add-Ins:TM-...assenGenerator

Ulrich

 

Geschafft!
Ulrich, tut mir Leid, dass du es mir noch mal vorkauen musstest. Eigentlich hätte mir den Hinweis

reichen müssen. Sobald ich Zeit hatte, richtig darüber nachzudenken, dann hats auch schon geklappt. Das hat mir also am Ende gefehlt, um die leeren Spalten in der Datenblattansich ausblenden zu können.

Falls jemand Lust hat, hier ist mein Code mit paar Erklärungen
Es geht also darum,

Ulrichs Idee

Code:

Ausgelöst wird es beim Laden des Formulars und beim Ändern des Unterrichtsfaches.

Also noch mal vielen Dank!!!

Da die ganze Idee hier recht viel Anstoß gefunden hat, liefere ich auf Nachfrage noch paar Infos für Interessierte nach.
Anbei meine Beziehungsübersicht. Die Inhalte einiger Tabellen sind noch Platzhalter.

@gpswanderer und andere, ich verstehe eure Idee einer n:m (bzw. 1:n)-Beziehung. Dadurch würde ich allerdings auf den Primärschlüssel in den einzelnen dia_Tabellen (wo die Beobachtungsnotizen gespeichert werden) verzichten müssen. Ich sehe den Reiz, dass ich so pro Schüler mehrere Notizen in jedem Beobachtungsschwerpunkt speichern könnte. Ich brauche aber in der Regel EINEN Iststand pro Kind und Beobachtungsschwerpunkt. Außerdem lebt die ganze Idee davon, dass ich im Sitzplan (siehe Screenshot) mehrere Schüler markiere und ihnen mit wenigen Klicks einen gewissen (ihnen gemeinsamen) Kommentar in die Beobachtungsspalte reinschreibe. Bei einer 1:n-Bezieung würde der Kommentar mehrfach pro Schüler in der Tabelle landen, da ich es an die SchülerID knüpfe. Mir geht es also nicht darum, viele Notizen pro Schwerpunkt zu sammeln, sondern die Beobachtung zum jew. Schwerpunkt möglichst schnell aktuell zu halten.
Und wenn ich doch mehrere Angaben festhalten will, kann ich sie mit einem Trennstrich und ggf. Datum versehen in einer "Zelle" speichern und später bspw. per Array auswerten.

Ich würde die Beziehungsstruktur also nicht als falsch bezeichnen, sie bildet einfach das ab, was ich brauche.
Oder sehe ich das falsch?

@evar46, ich bin mir nicht sicher, dass dir meine Beziehungsübersicht hilft, da sich unsere Anliegen doch recht unterscheiden. Aber wer weiß. Ich bleibe auch gerne im Kontakt, vielleicht können wir uns unterstützen.

 

Das ist aber erfreulich.
Richtig und falsch bei Datenmodellen ist recht schwierig und ich halte wenig davon Datenmodelle für andere zu erstellen.
Bei mir ist immer der erste Schritt mich mit dem nötigen Output und den Usern zu beschäftigen, bevor ich mich ans Datenmodell mache.

Für den Programmierer geht es aber auch oft darum, wie nachträgliche Erweiterungen umgesetzt werden.

Wenn ich dann sehe, dass du 7 identische Tabellen hast (die könntest du ja locker auf einen zusammenlegen. Nur ein Spalte mehr für den Bezug zum Fach/Thema), dann weiß ich auch, dass ich im einen Fall 7 Tabellen oder eine Tabelle anpassen muss. Dass geht dann weiter über die abhängigen Objekte usw.
Wenn ich aber nur in einer Tabelle ein Anpassung benötige, dann ist dein Modell möglicherweise besser.
Aber es spielt ja keine Rolle, die Arbeit hast ja eh du. *grins

 

Hallo,
da solltest Du aber noch mal darüber nachdenken.

Eine n:m Beziehung sind zwei 1:n Beziehungen, da geht auch kein Primärschlüssel verloren.

Auch diese Annahme ist falsch. In einer n:m Tabelle kommt ja noch ein weiteres Schlüsselfeld (zur Schwerpunkttabelle) und damit gibt es je Schüler und Schwerpunkt einen Datensatz.
Die dia Tabellen gehören in eine Tabelle zusammengefasst. Für die Titel der dia Tabellen ist eine weitere Tabelle erforderlich die die dia Tabellen mit dem Schüler verbindet. Das wird dann die besagte n:m Tabelle.
Die Beziehung zwischen den jetzigen dia Tabelle und dem Schüler kann auch nicht stimmen. Das kann doch keine 1:1 Beziehung sein, oder hat der Schüler nur eine einzige Note im Betragen ?

Das ist in einer Datenbank ein No-Go und verstößt bereits gegen die 1.Normalform (atomare Inhalte).

Die ganze Struktur enthält sehr viele handwerkliche Fehler. Du solltest Dich mit den Grundlagen zum Aufbau einer relationalen Datenbank beschäftigen. Du solltest Dir auch mal den Entwurf von evar46 ansehen, das scheint mir auch für Deinen Fall geeignet. Und da kannst Du auch einige (3 Stück) n:m Beziehungen sehen.

Auch die beiden anderen Tabellen bedürfen der Überarbeitung.
Da fehlen noch Tabellen, z.B. Medikamente/Alergien, denn auch da gilt, nicht mehrere Werte in einem Feld. Und schon gar nicht Medikamente und Alergien vermischt.

Mal noch eine Frage: In welcher/welchen Tabelle(n) wolltest Du jetzt Felder per Klick hinzufügen ?

Siehe hierzu:
A. Kelz: Relationale Datenbanken
und
Access-Tutorial: Lernen Sie Microsoft Access Datenbanken zu erstellen!

Und nicht zuletzt:
Die Feldnamen mit den vielen Leer und Sonderzeichen sind eine Katastrophe.
Du wirst gezwungen sein, für jeden Feldnamen den Du verwendest (egal wo, Abfragen, Formularbezüge, VBA usw.) ein [] Klammerpaar verwenden zu müssen. Das wird Dich noch ziemlich nerven.

 

Hallo Pavel,

kleine Korrektur für die Dim-Anweisungen:
Code:

Was deine Tabellen betrifft, solltest du auf jeden Fall den Rat beherzigen, Leerzeichen und Sonderzeichen aus den Feldnamen zu entfernen. Ich persönlich verzichte normalerweise auch auf den Unterstrich und verwende "CamelCase" für die Bezeichner. Ausnahme: Bezeichner, die dynamisch zusammengesetzt werden und der Unterstrich als "Trennzeichen" dient.

Ein andere Sache ist die Verwendung einer UUID als PrimaryKey. Da würde ich doch die gängigere Variante mit einem Long bevorzugen. Die UUID ist nämlich manchmal recht "sperrig" zu handhaben und bringt in diesem Fall keine Vorteile.

Gruß Ulrich

 

Hallo Ulrich,

wie immer, vielen Dank!
Das mit den Leerzeichen in Tabellenbezeichnungen und dem Primärschlüssel habe ich leider so geerbt. Die kommen so aus unserer Schuldatenbank, aus der ich meine Stammdaten habe. Für den späteren Datenupdate (wenn neue Schüler kommen, wenn ich mir aktualisierte Daten hole etc.) wollte ich die Bezeichnungen lieber so lassen.

Die Dim-Schreibweise wird geändert.

Pavel

 

Hallo gpswanderer,

danke dir für dein umfangreiches Kommentar.
Nach dem ich dein (entschuldige) "Rumgemotze" von wegen

etc. runtergeschluckt hab (bin kein Datenbankprogrammierer sondern Grundschullehrer und suche nur nach einer Alternative zum Stift und tausenden von Zetteln)
hab ich mir noch mal die n:m-Beziehungen angeschaut und möglicherweise endlich kapiert (siehe Bild).

Ok, du hast schon Recht. Das hat ja was. Ich brauche die Beobachtungskriterien nicht spaltenweise ausgeben, sondern habe sie zeilenweise in der Spalte Kriterien gespeichert. Dann ist es sicherlich einfacher per Formular weitere Beobachtungskriterien zu erfinden und die Übersicht der Beobachtungen muss nicht dynamisch erstellt werden. Richtig?

Es bleibt wahrscheinlich dabei, dass ich es im Prinzip in 1:1-Beiziehung nutze, da ich in aller Regel nur einen immer wieder aktualisierten Wert pro Beobachtungskriterium brauche aber wenn ich doch mal mehrere Einträge machen will, dann ist es ja möglich und einfacher auswertbar.

Nun ja, ich danke euch allen!
Ich habe ein/zwei Stündchen Schlaf, einen weiteren Tag mit den Kindern und dann noch viel Arbeit vor mir

Pavel

 

Das entspricht der Logik eines Wegwerfzettels.
Wenn man die Datenbank als Datenbank gebraucht, können nicht nur, sondern es werden garantiert mehrere Einträge über Zeiträume wie Schuljahr, Monat, Woche, Tag auftreten.
Daher wird dann auch die Thematik zeitliche Zuordnung und zuvorige Vergabe eines jeweiligen Zeitstempels eine größere Bedeutung erlangen.