Hallo @all,
ich bin wieder durcheinander gekommen. Daher nochmal so eine Frage:
Ich habe
* eine tblProbanden mit Probanden und [IDP] und [Rueckmeldung]
* eine tblRueckmeldungen mit [IDR] [Rueckmeldungen]
Ich möchte jetzt im (Einzel)Formular bei jedem dem Probanden ein kleines Endlosformular haben, in das n Rueckmeldungen eingetragen werden können, je nach dem wie viele es werden.
Muss man dazu jetzt eine dritte Tabelle anlegen, tblZRueckmedlungen, die [IDP] und [IDR] als Fremdschlüssel enthalten?
Carl
Hallo,
wenn es standardisierte Rückmeldungen sind ( was ich auf Grund der Tabelle annehme) ist diese 3. Tabelle zur Herstellung einer n:m Beziehung erforderlich.
Wie sonst soll es auch gehen, wenn es zu einem Probanden mehrere (n) Rückmeldungen geben kann ?
Da es in einer Datenbank keine mehrfachen Einträge in einem Feld geben darf ist diese 3. Tabelle auch zwingend erforderlich.
Der Proband wird dann im Hafo (das Einzelformular) angezeigt und die Rückmeldungen im Endlosformular als verknüpftes (über IDR und IDR_F) Ufo.
Auswahl der zutreffenden Rückmeldung per Kombifeld.
Danke für die Antwort. Die Rückmeldung soll ein Textfeld mit 255 Zeichen werden.
Also in der Zuordnungstabelle die Schlüssel beider Tabellen als Fremdschlüssel? Wie kriege ich im Beziehungsfenster den Beziehungstyp geändert? Es gibt nur eine Schaltfläche für den Verknüpfungstyp und wenn ich da eine der drei Optionen auswähle, ändert am Beziehungstyp nicht. Er steht jetzt auf 1:n, siehe Anhang.
und wieso bekomme ich das ausgefüllte Beziehungsfenster nur, wenn ich auf den mittleren Strick klicke? Wenn ich auf die kleine 1 oder das Unendlich-Zeichen klicke erscheinen neue unausgefüllte Fenster.
Carl
Hallo,
Die Rückmeldung soll ein Textfeld mit 255 Zeichen werden.das ist doch dann aber Freitext und keine standardisierten Texte (wie ich angenommen habe und auch geschrieben habe). Dann ist die Zuordnungstabelle natürlich überflüssig. Eine n:m Beziehung macht nur Sinn, wenn feste Rückmeldungen vorliegen die mit einem Kombi gewählt werden können. Was ja hier nicht der Fall ist.
Es soll aber zu jedem Probanden n solche Rückmeldungsfenster geben.
Diese Zuordnungstabelle finde ich besonders schwer einzurichten.
Kannst Du bitte sagen, weshalb ich das ausgefüllte Beziehungsfenster nur angezeigt bekomme, wenn ich auf den mittleren Strich klicke? Wenn ich auf die kleine 1 oder das Unendlich-Zeichen klicke erscheinen neue unausgefüllte Fenster.
Carl
Hallo,
ZitatEs soll aber zu jedem Probanden n solche Rückmeldungsfenster geben.
Keine n Fenster, sondern n Datensätze. Du brauchst keine n:m Zuordungstabelle. Das ist keine n:m Beziehung, sondern eine ganz normale 1:n Beziehung.
1=Probanten
n=viele Rückmeldungen
Darstellung eventuell in einem Endlosformular als Unterformular.
ZitatWenn ich auf die kleine 1 oder das Unendlich-Zeichen klicke erscheinen neue unausgefüllte Fenster.
Damit könntest Du neue Beziehungen anlegen. Das ist normales Verhalten. Mit Klick auf den Strich werden angelegte Beziehungen bearbeitet bzw. geändert.
Ach so, alles klar. Ja, verstehe.
Danke Carl
Ich habe das von der Durchführung her noch nicht verstanden.
tblProbanden mit dem Feld ProbandenRueckmeldungen
tblRueckmeldungen mit [IDR] und Textfeld [Rueckmeldungen]
Wie kann ich jetzt machen, dass in [ProbandenRueckmeldungen] das Feld der Tabelle Rueckmeldungen erscheint? Also als Endlosfeld, wie oben gesagt, für ein Endlosformular.
Ich habs von der Durchführung her noch nicht geschnallt.
Carl
Hallo,
nein, so nicht, aber so:
tblProbanden mit den Daten des Probanten und dem Primärschlüssel (IDP)
tblRueckmeldungen mit [IDR], dem Fremdschlüsselfeld (IDP_F) und Textfeld [Rueckmeldungen]
Beziehung von IDP (1) zu IDP_F (n).
Das ist die einfachste aller Beziehungen. Ich kann nicht ganz nachvollziehen, wo Du da Probleme hast.
Danke. Weil ich damit auf Kriegsfuß stehe, mir fällt das logische Denken schwer.
Ich habe jetzt ne Abfrage mit
[tblProbanden].[IDP]
[tblRueckmeldungen].[IDR], [tblRueckmeldungen].[IDP_F] und [tblRueckmeldungen].[Rueckmeldungen]
Diese Abfrage habe ich einem Formular unterlegt.
das über das HF aufgerufen wird mit dem Button:
Private Sub btnRueckmeldung1oeffnen_Click()
DoCmd.OpenForm "frmRueckmeldungen1", , , "IDP_F=" & [ID]
End Sub
Wenn ich in dem sich öffnenden Formular in dem Textfeld was eintrage kommt die Fehlermeldung:
Kann in der Tabelle tblprobanden keinen Datensatz mit passenden Schlüsselfeldern IDP_F finden.
Kann das mit dem von mir verwendeten Code für DoCmd.OpenForm zusammen liegen?
Carl
PS: Oder soll man das über die Abfrage so einrichten, dass immer automatisch die mit dem passenden Fremdschlüssel aufgerufen werden?
Hallo,
vergiss mal die Abfragen, Du brauchst hier erst mal keine Abfrage.
Das Hafo wird an die Tabelle "Probanten" gebunden und das Ufo an die Tabelle mit den Rückmeldungen. Hafo und Ufowerden über die Schlüsselfelder verknüpft.
Im Ufo kannst Du dann zu jedem Probanten beliegig viele Rückmeldungen erfassen, VBA Code braucht es da nicht, keinen Buchstaben. Da muss man auch nichts filtern.
Zeige mal ein Bild des Beziehungsfensters mit diesen beiden Tabellen.
Ach, okay. Ja, verstehe. Habs hin bekommen, es funktioniert. Vielen Dank.
Es gibt nur noch das Problem mit dem öffnen des HF. Ich öffne das HF derzeit mit einem Klick auf ein Textfeld:
=OpenPopUpfrmRueckmeldungen([Screen].[ActiveControl])
Im Modul steht:
Public Function OpenPopUpfrmRueckmeldungen(ctl As Control)
DoCmd.OpenForm "frmRueckmeldungen", , , "ID=" & ctl.Parent.ID, , acDialog, ctl.Value
End Function
Jetzt habe ich die ganze Zeit schon versucht, die selbe Funktion einem Button unterzulegen, aber Access bringt dann immer ne Fehlermeldung und meckert dann immer die Zeile im Modul an.
Wenn ich weiterhin das Textfeld verwende (in dem der Name des Probanden steht), funktioniert es, dass das HF geöffnet wird und auch die Openargs richtig angezeigt werden. Aber ich möchte einen Button. Woran liegt das, dass er die selbe Funktion mit dem button nicht macht? Ist das vielleicht, weil er mit "ctl.Parent.ID" die Eltern-Idee eines Feldes sucht und Button keine Felder sind?
Carl
Ein Knopf hat keine Value-Eigenschaft.
ah, danke
Wenn ich value entferne, funktioniert das Anzeigen der Openargs nur beim ersten Öffnen. Gleich beim zweiten Öffnen werden sie nicht mehr angezeigt.
Der Wert der Openargs soll aus dem Feld WOName entnommen werden.
Carl
Nochmal die Frage für openform,
ich möchte mit dem Modul das HF mit einer Schaltfläche öffnen, die natürlich keinen Wert hat.
'DoCmd.OpenForm "frmRueckmeldungen", , , "ID=" & ctl.Parent.ID, , acDialog, ctl.Value
DoCmd.OpenForm "frmRueckmeldungen", , , "ID=" & ctl.Parent.ID, , acDialog, WOName
Der Ausdruck "ctl.Value" soll nun durch einen Ausdruck ersetzt werden, der anweist, den Wert in die openargs zurück zu geben, der im Feld [WOName] steht. Ich habe schon mindestens zwei Dutzend Kombinationen durch, finde aber den richtigen Ausdruck nicht.
Wie kann man das anweisen?
Carl
Hallo,
mir ist immer noch völlig unklar was Du da programmieren willst.
Mir scheint auch, Du willst da mit Gewalt etwas programmieren, was man so gar nicht braucht.
Was steht denn im Feld "WOName", was willst Du denn da mit den Openargs erreichen ?
Wenn das Hafo ganz normal mit Openform geöffnet wird, zeigt das verknüpfte Ufo ganz automatisch die passenden Rückmeldungen an. Da muss man nichts programmieren.
Was ist denn "frmRueckmeldungen", das Hafo oder das Ufo ?
Wenn Du das bereits erbetene Beziehungsbild mal gepostet hättest, hätte ich Dir schon längst ein Beispiel gemacht.
WO-Name ist der Name des Probanden. Der soll angezeigt werden im HF, über den es Rückmeldung gibt.
frmRueckmeldungen ist das Hafo. Das Ufo heißt frmRueckmeldungenUFO.
Das Beziehungsfeld poste ich heute Abend.
Hallo,
sorry, aber Du programmierst hier Chaos. Und mit ziemlicher Sicherheit völlig überflüssig.
ZitatWO-Name ist der Name des Probanden. Der soll angezeigt werden im HF, über den es Rückmeldung gibt.
Wenn das Hafo an die Tabelle mit den Probanten gebunden wird, wird doch der Name des Probanten im Hafo bereits angezeigt, ganz automatisch. Wozu noch mal in den OpenArgs. Und außerdem, macht der Name keinen Sinn, weil die Verknüpfung über die ID des Probanten erfolgt.
Und außerdem, solltest Du etwas mehr Sorgfalt für Deine Antworten aufwenden.
Ich wollte das Beziehungsbild, nicht das Beziehungsfeld.
Und heißt das jetzt WOName oder WO-Name, das ist ein nicht unwichtiger Unterschied.
Es heißt WOName.
Kann man statt "ctl.Value" prinzipiell nicht den Inhalt eines anderen Feldes angeben?
Ich brauche die Funktion mit dem Ansteuern des Buttons noch für andere Zwecke.
Carl
Hier ist das Beziehungsbild
Hallo Carl,
Hast du #10 von Klaus nicht gelesen?
Du brauchst doch für das UFo gar kein "OpenForm", - ist doch im HFo
eingebettet und verküpft.
gruss ekkehard
Wenn eine Workorder immer einen Autor hat, reicht als Fremdschlüsselfeld die Workorder.
Und wenn das Formular zu voll ist, weil sich nicht normalisierte Daten darin drängen, so kann man sich mittels Formularassistent eine Verknüpfung zu einem zweiten Formular erstellen lassen. Dazu Tabelle WorkOrder und Tabelle Rueckmeldungen auswählen und vom Assistenten leiten lassen. Am Ende kannst Du dann den Code aus beiden Formularen in Deine richtigen Formulare adaptieren.
PS: Observationen (muss ja etwas langweiliges sein, wenn immer dasselbe beobachtet wird) wäre ein Kandidat für eine m:n-Beziehung (wobei auch hier der redundante Autor gestrichen werden kann). 1 WO beruht auf keiner, einer oder auf vielen Beobachtungen. Eine Beobachtung kann in keiner, einer oder in velen WOs auftreten. Gleiches gilt auch für die Batterien.
Zitat von: Beaker s.a. am Juni 04, 2018, 16:26:12
Hallo Carl,
Hast du #10 von Klaus nicht gelesen?
Du brauchst doch für das UFo gar kein "OpenForm", - ist doch im HFo
eingebettet und verküpft.
gruss ekkehard
Ja, ich habs gelesen und mache es ja so. Ich brauche aber das Openargs noch für andere Formulare, wo es einen Button gibt, der ein Formular öffnet, das nicht auf der selben Tabelle basiert, auf der das Eltern-Formular basiert. :-)
Carl
Zitat von: Lachtaube am Juni 04, 2018, 17:10:19
PS: Observationen (muss ja etwas langweiliges sein, wenn immer dasselbe beobachtet wird)
Gleiches gilt auch für die Batterien.
Ja, mit den Batterien hast Du Recht! Das will ich noch normalisieren. Wird schwierig.
Aber die Observablen sind auf 5 begrenzt, da brauche ich keine Zuordnungstabelle.
Nicht Observationen, sondern Observablen. Das sind Beobachtungsvariablen die real gemessene Werte enthalten, im Gegensatz zu statistischen Variablen, deren Zellenwerte aus Berechnungen entstehen wie beispielsweise bei Faktorvariablen oder Regressionsvariablen. Desswegen habe ich sie "Observablen" genannt, damit man später nicht durcheinander kommt. Es gibt auch Latentablen oder Residualvariablen usw..
Hallo Carl,
Zitatwo es einen Button gibt, der ein Formular öffnet, das nicht auf der selben Tabelle basiert, auf der das Eltern-Formular basiert. :-)
Aber da kannst du dir den Wert doch immer wieder aus dem bereits
geöffneten HFo abholen; - oder zur Not eine öffentliche Property
verwenden.
gruss ekkehard
Hallo Ekkehard, okay, ich frage dann nochmal nach wenn es an eine öffentliche property geht ....
Ist bei den Batterien wirklich die Normalisierung zu empfehlen? Auch wenn sie für immer auf maximal 12 Stück begrenzt sind? Bei den Batterien ist es so, dass sie Aufgaben bündeln, die gemeinsam an einem Tag vorgegeben werden. Mehr als 6-7 schafft eh kein Patient und ich habe vorsichtshalber ein Dutzend Leerstellen gemacht. Aber es können nie mehr werden. Es wird immer die gleiche Anzahl bleiben.
Hallo Carl,
ZitatNormalisierung zu empfehlen
Das ist keine Empfehlung, das ist Standard.
Zitatund ich habe vorsichtshalber ein Dutzend Leerstellen gemacht.
Heisst das, dass du eine Tabelle nach dem Muster "Aufgabe1, Aufgabe2,
usw." hast? Das wäre falsch. Pro Aufgabe ein DS mit FK zur Batterie und
zum Patienten (vermute ich mal ohne weitere Kenntnisse, kommt aber
wohl eher noch eine n:m-Tabelle dazu).
gruss ekkehard
Hallo,
das ganze Datenmodell krankt hinten und vorn.
Für die Batterien und die Observablen ist unbedingt Normlaisierung vorzusehen mit Zuordnungstabellen als n:m. Und wie von ekkehard bereits gesagt, ist das keine Empfehlung, ds ist ein muss. Das ganze Beziehungsgeflecht wird ja dadurch viel einfacher, weil die Mehrfachverwendung von Tabellen ersatzlos entfällt. Wenn Du das so lässt, wird zur Unterscheidung der Feldinhalte stets der komplette Bezug benötigt, also TabellenName_1!Feldname, TabellenName_2!Feldname usw. Außerdem sind alle Abfragen die Du erstellst (mit den Mehrfachtabellen) zunächst mal falsch und müssen manuell gem. Beziehungsbild geändert werden. Und das jedes mal, wenn Du eine Abfrage erstellt. Das ist völliger Krampf und jedes mal ein Haufen Arbeit. Ich glaube, Du bist Dir über den Aufwand nicht im Klaren der notwendig ist, wenn Du bei Deinem unnormalisierten Aufbau bleibst.
Du wirst keine andere Wahl haben, als das korrekt aufzubauen. Es macht auch keinen Sinn, Formulare anzulegen bevor das Datenmodell nicht OK ist. Sonst kannst Du das alles in die Tonne treten. Das gilt sinngemäß auch für Berichte.
Und dann noch die vielen ID Felder, auch das solltest Du bereinigen.
Die ID bei den Autoren heißt IDAutor und das Fremdschlüsselfeld dann IDAutor_F. Wenn Du da keine vernünftige einheitliche Nomenklatur aufbaust, blickst Du in Deiner eigenen DB nicht mehr durch.
Nun, zum Zweck der Geschichte kann ich nichts beitragen, aber wenn einfache Abfragen anstehen, wie: liste mir alle alle Bündel nach der Anzahl der Häufigkeiten, oder zeige mir die Bündel, die Autor A und Autor B gemeinsame haben, oder zeige mir die Bündel, die weder A noch B haben, so ist das mit Deiner Datenform kaum zufriedenstllend zu bewerkstelligen. Das bezieht sich sich auf alle Gruppierungen - also auch Deine Variablen. Es würde ja auch niemand eine Einkaufstabelle erstellen und z.B. 10 Blöcke für Artikel, Preis und Menge anlegen (für mehr als 10 Artikel ist nie Geld vorhanden).
Ein weiterer Nachteil ist, dass verschwenderisch mit Indexen umgegangen wird, denn es wird für jedes Feld der Gruppe ein Index eigener Index erzeugt.
Merke: Gleiches oder Ähnliches speichert man in der Regel in Datensätzen untereinander ab und kennzeichnet die Datensätze mit Fremdschlüssel und ggf. weiteren Attributen (z.B. eine Batterie-Nummer von 1-12), um sie voneinander unterscheiden zu können.
Es war mir schon klar, warum Ihr das Fenster sehen wolltet ... :-)
Das alles mache ich nach und nach. Das läuft ja jetzt erstmal ganz gut und jetzt alles neu zu ändern habe ich einfach keine Zeit. Es wird nächstes Jahr sowieso durch einen Programmierer neu aufgesetzt mit Login für User usw..
Ihr habt scheinbar keine Vorstellungen, wie schwierig das für einen Fachfremden ist, sich durch das alles zu ackern und ans Laufen zu bekommen ...
PS: Und mit den vollständigen Pfaden in den Batterien, da werden ja keine Daten eingegeben sondern lediglich Listen von Namen angezeigt, deren Einträge noch dazu aus Abfragen kommen. Es entstehen ja keine neuen Datensätze an dieser Stelle. Da wird ne Liste angezeigt, bei der der Betreuer sieht: "Ach so, die sollen heute diese und jene Übungen machen." Da wird nichts gemessen oder so. Und ich könnte gegen 100 zusätzliche Arbeitsstunden noch viel mehr Ausreden nennen, wenn ich welche wüsste!
Carl