Office: (Office 2010) Formular wird in der Formular-/Layoutansicht nicht angezeigt

Hallo,
ich blicke zwar auch nicht durch, aber schließe mich im Wesentlichen der Meinung von Martin an.

Und noch mal meine Meinung, Dein Vorhaben wird Dir nicht gelingen weil es schlichtweg unmöglich ist. Es macht auch bei diesem umfangreichen Datenmodell keinen Sinn auf einfache Hafo/Ufo Konstruktionen verzichten zu wollen.

 

Moin,
so auf den ersten Blick sieht das aus wie eine klinische Studie?
Vielleicht kann ich da ja ein paar (unsortierte) Anregungen geben, wie sich das Datenmodell etwas entzerren lässt (die Zeit, das jetzt im Einzelnen durchzuflöhen hab' ich grad nicht und ohne genauere Kenntnis des Ablaufs ist es auch schwierig). Darstellung und Eingabe per Formular wird sich danach vermutlich auch wesentlich einfacher gestalten.

• Warum gibt es eine Tabelle für "NewPatient" und eine für "PatientItems"?
• Der Parameter "unknown" lässt sich gut als Kodierung in alle Felder direkt eintragen. Also nicht FeldBla und FeldBlaUK, sondern nur FeldBla, in dieses wird z.B. ein Wert 99998 eingetragen, der die Kodierung für unknown ist.
  Das verhindert auch, dass du plötzlich einen Wert in Bla hast und trotzdem auch bei BlaUK unknown eingegeben ist. 99997 wäre dann z.B. "ongoing", 99996 "not applicable", usw. Diese Kodierung funktioniert bei Zahl und Text problemlos, bei Datum und Zeit hast du kryptische Werte (99998 wäre z.B. der 12.10.2173), die du aber ausblenden oder anders anzeigen kannst. Ich mache diese Kodierungseinträge über ein Kombifeld im Fuß des Formulars, mit dem ich diese Werte per Code für jedes Formularfeld zuweisen kann.
• Yes/No/NotDone/Unknown-Felder kannst du auf Datentyp Zahl einstellen, sie bekommen ebenfalls eine Kodierung: Yes = 1, No = 2, Not done = ...
• Beispiel Tabelle DangerSignals (möglicherweise auch bei anderen so): Das sieht mir ein bisschen nach Excel-Tabelle aus, jede DS-Art ein Feldchen. Da wird nur ein Feld gebraucht, in dem das jeweilige DS bzw. eine entsprechende Zahl als Fremdschlüssel (1 = Bleed, 2 = Trauma, 3 = Surgery ...) eingetragen wird. Mehrere DangerSignals ergeben genausoviele Datensätze. Kein Signal = kein Datensatz. Unklares DS -> Kodierung für unknown oder ähnlich eintragen.
• First Bleeding sollte z.B. ein ja/Nein Feld in der Tabelle Bleedings sein (so gravierende Unterschiede sehe ich nicht zwischen den Informationen), damit entfällt die FirstBleeding-Tabelle komplett. Um sicherzustellen, dass für jeden Patienten nur einmal First Bleeding angegeben wird, kannst du eine Prüfung einbauen.
• Von Mehrwertfeldern rate ich dringendst ab. Das lässt sich nur schwer auswerten - mach da mal eine Häufigkeitsabfrage drauf (Wie viele Patienten haben eine Blutung am großen Zeh?). Löse das mit einer Detailtabelle, bzw. bei Bleeding bspw. mit je einem Datensatz pro Location.
• Sollte es sich wirklich um eine Studie handeln, so wird es vermutlich Visits geben. Nach diesen Visits organisiere ich meine Formulare normalerweise: Eines, in dem ich PatID und Visit-Nr. auswähle und entsprechend die Daten (zum Bearbeiten) angezeigt bekomme. Ein paar Buttons zum Aufruf weiterer Formulare (Comedikation, Labor, ...). Das war's dann schon im Wesentlichen.

HTH,
Maike

 

Solche magic numbers sind schlechter Stil, denn die Nummer ist von "echten" Werten kaum zu unterscheiden. Und sie könnte vielleicht sogar mal als legaler Wert auftauchen. Unbekannte Werte sollten in der Regel als NULL-Werte (d.h leer) erfasst werden oder, wenn ein expliziter Wert als Eingabenachweis nötig ist, als Wert mit Flag "IstUnbekannt" (J/N-Kennzeichen o.ä.) erfasst werden.

 

Hi Martin,
im Prinzip hast du ja Recht. In der klinischen Forschung regiert aber die FDA (Food and Drug Administration).
"Unbekannt" kann hier viele Ausprägungen haben, die auch ersichtlich sein und erfasst werden müssen. Unbekannt ist nicht das Gleiche wie "nicht untersucht" oder "nicht zutreffend" oder "Unterlagen fehlen" oder "kein Enddatum, weil weiterbestehend" oder ...
Ein echter NULL-Wert erfordert hier in jedem Fall eine Rückfrage, die dann entweder einen konkreten Wert oder eine der oben genannten Ausprägungen von NULL ergibt.
Die Magic-Numbers haben den Vorteil, dass sie bei den meisten Datentypen funktionieren und da wir uns hier im Bereich der Medizin bewegen, ist 99998 etc. ein Wert, der in der Regel ausserhalb des zu erwartenden Bereichs liegt. Ich weiß, in der Regel ist nicht dasselbe wie "nie".
Wenn du eine bessere Idee hast für das Problem, dann rück' 'raus *wink.gif* .
maike

 

Hallo Meike,

danke für deine Antwort!
Du hast recht, es bewegt sich im Bereich klinischer Studien. Es soll allerdings eine DB werden um retrospektiv verschiedene klinische Studien zu betrachten. Deswegen ist das auch mit den verschiedenen Visits schwierig und die Formulare lassen sich so nicht sortieren. Und deswegen gibt es auch NewPatient und PatientItems, weil irgendwo eine Verschlüsselung der Datenquelle (Welcher Patient aus welcher Studie) stattfinden muss, so dass die Patienten bei Abfragen nur noch über eine datenbankinterne Nummer identifiziert werden können.

Das mit den magic numbers finde ich eine gute Anregung. Es spart mir zumindest an einigen Stellen zusätzliche Felder und zusätzliche Plausibilitätsprüfungen.

Zu den Danger Signals: Jede DS-Art ist ein multiple Choice-Feld, das angekreuzt werden kann, gefolgt von einem Freitext, in dem die Art des Danger Signals spezifiziert werden kann, also z.B. Kreuzchen bei "Trauma" und im Freitext "Kopfwunde" oder Kreuzchen bei "Surgery" und im Freitext "Entfernung eines Backenzahns". Und das brauche ich auch so genau, weil es natürlich wichtig ist, ob es vermehrt Fälle von Kopfwunden gibt, weil den Patienten einfach oft schwindelig wird, oder ob es z.B. vermehrt zu Zahnverlust kommt, weil irgendetwas dazu führt, dass das Kalzium aus den Zähnen abgebaut wird und die nur noch wegbröckeln.

Aber vielleicht lassen sich die multiple choice Felder auch umgehen. Ich gehe mal schauen, wo ich überall welche habe.

Oh, wofür steht eigentlich "HTH" ?
"Halt Tie oHren steif"?

HTH
Jasha

 

Hab schon:

Heißt: die 99998 ist nicht "unbekannt", weil das die zufällige Bedeutung dieser Kennzahl ist, sondern sie wird durch ein spezielles Kennzeichen (J/N) zum Unbekannt-Flag. Aufbau also:
Code:

Vorteile:

• der Unbekannt-Fall ist narrensicher erkennbar, ohne magic numbers
• Änderungen sind möglich, wenn der Wert 99998 doch mal für echte Daten steht

Alternativ könnte man die magic numbers auch in einer Tabelle ablegen. Man muss halt dran denken, diese Tabelle dann mit einzubinden.

 

Hallo,

wäre vielleicht ein Navigationsformular die Lösung?
Wenn ich meine 30 Tabellen alle einzeln in eigene Formulare umwandel und diese dann in ein Navigationsformular einbinde?

Ich habe über das Navigationsformular folgendes gelesen:
"Bei einem Navigationsformular mit 2 Navigationsleisten (oben und links) sind die Reiter links hierarchisch von den Reitern oben abhängig."

Heisst das, ich könnte oben das definieren, was ich gerne als zusammengesetztes Formular gemacht hätte (also z.B. ein Reiter mit "Basisdaten") und dann, wenn dieser Reiter aktiviert ist, links auf den Reitern meine einzelnen Tabellen hinterlegen (also z.B. die Tabelle PatientItems, die Tabelle Diagnose und die Tabelle Genetische Spezifikationen?).
Dann nehme ich den zweiten Reiter oben, nenne den "Behandlung vor Studienstart" und den dritten "Behandlung nach Studienstart" und packe jeweils unter die linken Reiter die auszufüllenden Tabellen?

Hat jemand von euch sowas schon mal gemacht? Ginge das?

LG
Jasha

 

Hallo,

ich habe mal als Beispiel den Screenshot eines Formulars mit diversen Unterformularen aus einer meiner Anwendungen als Screenshot angefügt.
Das Datenmodell dahinter ist auch etwas komplexer. Die Daten selber sind aus Geheimhaltungsgründen "wegradiert".

HTH heißt übrigens "Hope This Helps"...

Gruß
Fred

 

Hallo,
zum Naviformular ist heute bei

http://www.smarttools.de/newsletter/...newsletter.php

ein Artikel erschienen. Melde Dich dort an, dann bekommst Du den Artikel auch.

Alternativ, teile mir Deine Emailadresse mit (per PN) dann schicke ich Dir den Artikel. Aber die Anmeldung zum Newsletter bei obiger Seite loht auf jeden Fall.

 

Hallo Fred,

ja, ich glaub, das isses! *Smilie

Eine Frage noch: Dass bei dir oberhalb der Reiter noch Felder zum Ausfüllen sind liegt daran, dass das ein geteiltes Formular ist? Oder hast du die einfach in den Formularkopf gepackt?


LG
Jasha

 

Hallo Klaus,

habe mich direkt dort angemeldet, danke für den Tipp. Den Newsletter erhalte ich allerdings erst ab der nächsten Ausgabe. Wäre also super, wenn du mir den Artikel schicken könntest. PN mit meiner Emailadresse schicke ich dir sofort.

Danke und LG
Jasha

 

Hallo,

Den Vorschlag gab es schon in #10 von Anne:

dem ich mich in #13 angeschlossen habe. *grins

 

Hallo,

das ist ja interessant, wo die doch die neueren Access-Versionen angeblich gar nicht unterstützen:

*biggrin.gif*

Der Newsletter würde mich ehrlich gesagt auch interessieren...

 

Huhu Klaus,

jepp. Mir war nur nicht klar, dass ein Registersteuerelement ein Navigationsformular ist. *rolleyes.gif*

Aber ich entwickel mich *wink.gif*

LG
Jasha

 

Moin *wink.gif*
@Jasha
so ein Hauptformular mit Reitern (Registersteuerelement) und Unterformularen wie vorgeschlagen scheint mir auch eine gute Idee für deine Situation.
Würde trotzdem die Tabellen noch mal überarbeiten. Die DangerSignals (als Beispiel) sind leichter auszuwerten, wenn du sie in dieser Form in der Tabelle verwaltest:
Code:

Auch lassen sich so Änderungen (Hinzufügen weiterer Signale z.B.) machen, ohne dass du die Struktur der Tabellen, Abfragen, Formulare, Berichte ... wieder anpassen musst.

@Martin
Das Unbekannt-Flag ist eine gute Idee, hatte ich oben überlesen, sorry.
Was meinst du mit "Alternativ könnte man die magic numbers auch in einer Tabelle ablegen"? Ich würde die Sache so organisieren, dass ich PK, Tabellenname, Feldname und "Unbekannt" für jeden dieser Fälle in einer separaten Tabelle mitführe, um nicht für nahezu jedes Tabellenfeld noch ein boolsches Unbekanntfeld in den einzelnen Tabellen zu haben.
War das so zu verstehen?

maike