Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

Zuordnungstabelle nochmal

Begonnen von Carl, Mai 24, 2018, 23:52:57

⏪ vorheriges - nächstes ⏩

MzKlMu

#15
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.

Gruß Klaus

Carl

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.

MzKlMu

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.
Gruß Klaus

Carl

#18
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

Beaker s.a.

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
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

Lachtaube

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.
Grüße von der (⌒▽⌒)

Carl

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

Carl

#22
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..

Beaker s.a.

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
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

Carl

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.

Beaker s.a.

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
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

MzKlMu

#26
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.
Gruß Klaus

Lachtaube

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.
Grüße von der (⌒▽⌒)

Carl

#28
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