collapse

* Benutzer Info

 
 
Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?

* Wer ist Online

  • Punkt Gäste: 57
  • Punkt Versteckte: 1
  • Punkt Mitglieder: 2
  • Punkt Benutzer Online:

* Forenstatistik

  • stats Mitglieder insgesamt: 14066
  • stats Beiträge insgesamt: 67523
  • stats Themen insgesamt: 9099
  • stats Kategorien insgesamt: 5
  • stats Boards insgesamt: 17
  • stats Am meisten online: 415

Autor Thema: Zuordnungstabelle nochmal  (Gelesen 932 mal)

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 7423
Re: Zuordnungstabelle nochmal
« Antwort #15 am: Juni 04, 2018, 10:20:44 »
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.

« Letzte Änderung: Juni 04, 2018, 10:27:59 von MzKlMu »
Gruß
Klaus
 
Folgende Mitglieder bedankten sich: Carl

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 395
Re: Zuordnungstabelle nochmal
« Antwort #16 am: Juni 04, 2018, 14:06:08 »
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.
 

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 7423
Re: Zuordnungstabelle nochmal
« Antwort #17 am: Juni 04, 2018, 14:23:43 »
Hallo,
sorry, aber Du programmierst hier Chaos. Und mit ziemlicher Sicherheit völlig überflüssig.
Zitat
WO-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
 

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 395
Re: Zuordnungstabelle nochmal
« Antwort #18 am: Juni 04, 2018, 14:33:20 »
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
« Letzte Änderung: Juni 04, 2018, 14:44:44 von Carl »
 

Online Beaker s.a.

  • Access Guru
  • ****
  • Beiträge: 1885
Re: Zuordnungstabelle nochmal
« Antwort #19 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
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.
 
Folgende Mitglieder bedankten sich: Carl

Offline Lachtaube

  • Access Guru
  • ****
  • Beiträge: 1336
Re: Zuordnungstabelle nochmal
« Antwort #20 am: Juni 04, 2018, 17:10:19 »
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 (⌒▽⌒)
 
Folgende Mitglieder bedankten sich: Carl

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 395
Re: Zuordnungstabelle nochmal
« Antwort #21 am: Juni 04, 2018, 18:06:37 »
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
 

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 395
Re: Zuordnungstabelle nochmal
« Antwort #22 am: Juni 04, 2018, 18:09:23 »
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..
« Letzte Änderung: Juni 04, 2018, 18:14:18 von Carl »
 

Online Beaker s.a.

  • Access Guru
  • ****
  • Beiträge: 1885
Re: Zuordnungstabelle nochmal
« Antwort #23 am: Juni 04, 2018, 18:32:55 »
Hallo Carl,
Zitat
wo 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
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.
 
Folgende Mitglieder bedankten sich: Carl

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 395
Re: Zuordnungstabelle nochmal
« Antwort #24 am: Juni 04, 2018, 18:54:42 »
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.
 

Online Beaker s.a.

  • Access Guru
  • ****
  • Beiträge: 1885
Re: Zuordnungstabelle nochmal
« Antwort #25 am: Juni 04, 2018, 19:15:29 »
Hallo Carl,
Zitat
Normalisierung zu empfehlen
Das ist keine Empfehlung, das ist Standard.
Zitat
und 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
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.
 
Folgende Mitglieder bedankten sich: Carl

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 7423
Re: Zuordnungstabelle nochmal
« Antwort #26 am: Juni 04, 2018, 19:18:41 »
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.
« Letzte Änderung: Juni 04, 2018, 19:31:54 von MzKlMu »
Gruß
Klaus
 
Folgende Mitglieder bedankten sich: Carl

Offline Lachtaube

  • Access Guru
  • ****
  • Beiträge: 1336
Re: Zuordnungstabelle nochmal
« Antwort #27 am: Juni 04, 2018, 19:43:42 »
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 (⌒▽⌒)
 
Folgende Mitglieder bedankten sich: Carl

Offline Carl

  • Access-Profi
  • **
  • Beiträge: 395
Re: Zuordnungstabelle nochmal
« Antwort #28 am: Juni 04, 2018, 20:14:01 »
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
« Letzte Änderung: Juni 04, 2018, 20:57:31 von Carl »