Tabellen ohne Referenz in Access-Formular zusammenführen

[crystal]

Hallo nochmal.

Die bisher vorgestellten Lösungen zeigen ja "nur" unterschiedliche Datenmodelle, aber keine Funktionalität.
Ich habe mir jetzt die letzte DB heruntergeladen und eine Tabelle und ein Formular hinzugefügt.

Dies ist ein stark reduziertes Beispiel, aber vielleicht geht es so ungefähr in die Richtung, was sich Der_Schanko an Funktionalität vorstellt.

OK - ich arbeite dabei (bewusst) mit Redundanzen. Auch müsste man vielleicht noch einbauen, dass nur die jeweils letzten 10 oder 20 Datensätze angezeigt werden, evtl. mit select top 20... und absteigender Sortierung.

Aber insgesamt scheint es mir doch eine ergonomische Lösung zu sein oder zumindest eine Basis.

Übrigens sieht man in meiner Mini-Lösung auch, wie man ganz genau einen Record in einem Endlos-Formular updaten kann. Das ist wohl auch interessant.

(Um das Formular zu finden, muss man im Navigations-Bereich z.B. "Alle Objekte" anklicken. Das Formular hat den Namen GS1, den Namen der DB habe ich auf hh (HandHeld) abgekürzt.)

Grüsse

crystal

(Datenmodell = dm.png, Formular-Bsp. = form.png, accdb + mdb = hh.zip)

[crystal]

PS: eigentlich ist es nicht nötig, meine neue Tabelle ins DM einzufügen und Referenzen auf andere Tabellen zu definieren, da alles im Formular stattfindet.

Für eine Lösung, die dem Umfang des DM entspricht, müsste man wohl noch etwas mit "Selects" für weitere Kombifelder arbeiten und auch weitere abhängige Felder "manuell holen" bzw. die Kombifeld-Selects passend komplex mit allen erforderlichen Joins erweitern...

[crystal]

Hallo Profis,

noch einige Fragen zum Verständnis.

In meiner kleinen Lösung (s.o.) nutze ich ja prinzipiell folgenden Code:

Code [Auswählen] Erweitern


Private Sub GSGerätRef_AfterUpdate()
    Me.Recordset.Edit
    Me.Recordset.Fields("text14") = Me.GSGerätRef.Column(1)
    Me.Recordset.Update
End Sub


also im Wesentlichen Zugriffe auf Recordset.

In meinem Verständnis ist ein Recordset aber eine Anzahl von Records. Warum greift aber
Me.Recordset.Fields("text14") = Me.GSGerätRef.Column(1)
genau auf den aktuellen Record zu? Ist einfach nur das Wort Recordset falsch und es müsste eigentlich Record heißen? Oder nimmt Recordset implizit immer den aktuellen Record (so wie es scheint)?

Wenn es RecordSET gibt, wieso gibt es dann kein Recordset(i) oder ActualRecord?

Es würde mich ja schon brennend interessieren, was Microsoft hier implementiert hat. Können wir im nächsten Release Antworten auf diese Frage erwarten? Sollte es dann vielleicht möglich werden, den "Fokus" oder "Scope" in einem Endlos- oder Unterformular auch "offiziell" auf einen Record des Recordsets zu beschränken?

Vom Ansatz her ist Recordset ja wohl eher als eine Auflistung zu verstehen, was ja durchaus logisch wäre. Hat Microsoft einfach nur vergessen, dem Programmierer Möglichkeiten zu bieten, auf einzelne Elemente eines Recordsets, also Records, zuzugreifen?

Gibt es API-Funktionen, mit denen das möglich wäre?

Ist mein Trick (s.o. im Codefenster) bekannt (ich habe ihn durch simples Probieren nach Inspektion des Lokal-Fensters gefunden)?

Wird durch Recordset.Edit der "Fokus" bzw. "Scope" "automatisch" auf den aktuellen Record gesetzt?

Funktioniert mein "Trick" nur deshalb, weil alle sichtbaren Felder meines Formulars direkt mit der zugrunde liegenden Tabelle korrespondieren und ich mit
Me.Recordset.Fields("text14") = Me.GSGerätRef.Column(1)
direkt in die Tabelle schreibe (und nicht in das GUI)?


Fragen über Fragen - wer kennt Antworten?

-------------------
Zur eigentlichen Fragestellung noch ein paar Ideen:

In den Eigenschaften eines Kombifeldes kann man die Anzahl der Spalten und deren Breite (z.B. auch 0) einstellen. Trotzdem kann man auf alle Spalten-Inhalte mit column(i) zugreifen, auch wenn die Breite 0 ist.
Man kann also durchaus komplexe Abfragen formulieren, nur die interessanten Datenfelder darstellen (andere auf Breite 0 setzen) und dann mit VBA auf alle Spalten zugreifen.

Statt - wie in meinem Beispiel - explizit Felder für Nachname und Vorname in der Tabelle zu halten, könnte man diese beiden Werte natürlich auch in einem gemeinsamen Feld unterbringen. Über die gespeicherte ID hätte man ja trotzdem die Möglichkeit, alle Fremdfelder einzeln anzusprechen.

Die jetzige einfache Abfrage der Geräte-Tabelle könnte man mit einer Union-Abfrage auch auf Geräte-Kombinationen erweitern und dann im Code entsprechend agieren.

Statt dem gesamten Formular eine Abfrage wie Select Top... zu verpassen, könnte man auch einfach alle DS suchen, die noch kein Rückgabe-Datum haben, oder alle, die seit vorgestern ausgegeben wurden, oder oder oder.

Durch Klick auf einen Info-Button im Endlos-Formular könnte man weitere Details des Datensatzes in einem modularen Formular (ähnlich einer Messagebox) anzeigen.

Was haltet ihr von meiner kleinen Lösung? Ich würde mich sehr freuen, wenn ich hierzu ein paar Antworten erhalten würde.

Gruß und ein schönes Wochenende...

crystal

[ebs17]

Vorab: Es macht keinen Sinn, aber einen schlechten Eindruck, wenn Du eigene Unfertigkeiten und Unkenntnisse Microsoft anlastest.

Code [Auswählen] Erweitern

    Me.Recordset.Edit
    Me.Recordset.Fields("text14") = Me.GSGerätRef.Column(1)
    Me.Recordset.Update
... ist gleichlautend (aber umständlicher) zum üblichen

Code [Auswählen] Erweitern

    Me.text14 = Me.GSGerätRef.Column(1)
Im zweiten Fall ist immer das Textfeld im aktuellen Datensatz addressiert.
Wenn man das Formularrecordset verwendet, ist da der Datensatzzeiger auf dem gleichen Datensatz wie im Formular und somit auch auf dem im Formular aktuellen.

Es würde mich ja schon brennend interessieren, was Microsoft hier implementiert hat.

Wenn Du das Objekt Recordset kennenlernen möchtest, wäre der Objektkatalog (mit Taste F2 aus VBA-Editor heraus erreichbar) eine übliche Informationsquelle zu den möglichen Eigenschaften, Methoden und Ereignissen dazu.

Man kann also durchaus komplexe Abfragen formulieren, nur die interessanten Datenfelder darstellen (andere auf Breite 0 setzen) und dann mit VBA auf alle Spalten zugreifen.

Ja, man kann auch zusätzlich zu den Schuhen an den Füßen seine sämtlichen anderen Schuhe im Rucksack mitführen.
Im Normalfall macht man seine Abfragen so schlank und schnell wie möglich.
Abfragen mit vielen Feldern im SELECT-Teil würde ich nun nicht als komplex bezeichnen, breit trifft es sicher besser.

[crystal]

Hallo Eberhard,

danke für deine Antwort, die mich leider etwas enttäuscht hat. Ich hatte nämlich gedacht, einen tollen Trick gefunden zu haben, weil ich im Lokalfenster über Recordset.edit gestolpert bin.

Mein sich wiederholender Verdacht, dass MS bei der Implementierung nicht sorgfältig genug war, rührt schlicht daher, dass es unmöglich ist, ein Produkt wie Access fehlerlos zu entwickeln. Die Unmenge an KB-Artikeln nur für Access spricht da Bände. Entsprechendes gilt natürlich für alle Software-Produkte, sein sie von MS oder irgendeinem anderen Hersteller.

Ich weiß natürlich inzwischen, dass du ein nahezu extremer MS-Fan bist, der auf MS nichts kömmen läßt. Insofern macht dein "Vorab-Satz" auch keinen Sinn und ist nur Polemik und etwas Provokation. Danke trotzdem für die fachliche Aufklärung, die auch völlig ohne deine "Randbemerkung" ihren Sinn und Zweck erfüllt hätte.


Mit "komplexen Abfragen" meinte ich übrigens Abfragen über mehrere Tabellen mit entspr. vielen Joins, nicht die Anzahl der selektierten Felder. Ich wollte mit der Spaltenbreite 0 nur klar machen, das man für die optische Darstellung des Pulldown-Fensters einer Kombobox an der Benutzer-Oberfläche Felder einfach verstecken kann oder könnte und im VBA-Code trotzdem darauf zugreifen kann. Sicher kein schlechter Weg, um dem Benutzer vor für ihn nur verwirrende Daten auszublenden und die Breite des Pulldown-Fensters zu reduzieren.

Auch hier wieder ein völlig unnötiger Satz (der mit den Schuhen), der nur zu einigen Lachern führt, wenn man an die Damenwelt denkt.

----------

Letztendlich will ich mit meiner kleinen Lösung nur das anbieten, was der Threadstarter sich so vorgestellt hat: eine übersichtliche Darstellung des Verbleibs der Geräte mit der Option, im selben Formular auch weitere Geräte auszugeben und dabei komfortabel via Kombifeld auf hinterlegte Daten zugreifen zu können. Meiner Grundidee folgend kann man beliebige Felder aus beliebigen Tabellen holen und simpel und ergonomisch darstellen und zur späteren Verwendung so speichern, wie man sie am Bildschirm sieht.

Die zugrunde liegende Tabelle kann man dann zyklisch von alten Datensätzen befreien, ohne sich die Möglichkeit zu verbauen, zuvor andere Auswertungen in Form von Berichten und Statistiken, monatlicher Meldung an die Kostenkontrolle, Verlustmeldungen, Reparaturen usw. zu erstellen.

Das alles wird jetzt relativ einfach, allerdings unter Billigung von Redundanzen, möglich und das elaborierte Datenmodell leistet seinen erheblichen Anteil zur Strukturierung und Verwaltung der Basisdaten.

Und ich will zusätzlich zeigen, dass es möglich ist, sehr kompakte Formulare zur Darstellung und Eingabe von Daten zu gestalten, wenn man bereit ist, Redundanzen in Kauf zu nehmen.

Eine Alternative wäre es, im Endlos-Formular erst bei der Darstellung per VBA die abhängigen Felder (z.B. Name und Vorname aus der MA-Tabelle) anhand gespeicherter Referenzen (MA-Id) zu holen und in ungebundene Felder zu schreiben (mit damit verbundenen Problemen, die Endlosformulare so haben). Damit verliere ich allerdings die Information, wer vor 5 Tagen Schichtleiter von MA XY war, es sei denn, ich ergänze die MA- und Schichtleiter-Tabelle um eine durchgängige Zeiten-Verwaltung. Die Frage ist, ob sich ein solcher Aufwand lohnen würde.

Ich bin gespannt, was Der_Schanko dazu sagt.

Grüsse

crystal

[MzKlMu]

Hallo,

Ich wollte mit der Spaltenbreite 0 nur klar machen, das man für die optische Darstellung des Pulldown-Fensters einer Kombobox an der Benutzer-Oberfläche Felder einfach verstecken kann oder könnte und im VBA-Code trotzdem darauf zugreifen kann. Sicher kein schlechter Weg,

da hast Du nichts neues erkannt. Das ist übliches Vorgehen seit es Access gibt. Nahezu jedes Kombi ist so eingestellt. Und wenn man mit dem Assistenten ein Kombifeld anlegt wird das standardmäßig so eingerichtet.

Noch etwas zu den Redunundanzen, diese sind in jedem Fall in einem korrekten Datenmodell zu vermeiden. Sie sind Fehlerquellen und bergen die Gefahr von Dateninkonsistenzen weil bei der Aktualisierung redundanter Felder etwas nicht geklappt hat.
Und meine langjährigen Erfahrung nach in mehreren Foren zeigt, dass ein falsches Datenmodell immer einen erhöhten und dann unnötigen Programmieraufwand erfordert.
Ein gutes Datenmodell zeichnet sich dadurch aus, dass man nur die Benutzeroberfläche mit Datenvalidierung programmieren muss. Datenkonsistenz sollte sich nur über das Datenmodell ergeben. Auch Unionabfragen sind nur in wenigen Ausnahmefällen sinnvoll.
Und im Rahmen dieser Erfahrung in den Foren habe ich auch festgestellt, dass von den vielen MS angelasteten Access Bugs nur weniger als eine Handvoll als Bug übrig bleiben. Spontan wüsste ich keinen. Und die KB-Artikel umfassen im wesentlichen Hinweise zum Umgang mit Access, würde ich daher eher als Hilfe bezeichnen.

Eine Alternative wäre es, im Endlos-Formular erst bei der Darstellung per VBA die abhängigen Felder (z.B. Name und Vorname aus der MA-Tabelle) anhand gespeicherter Referenzen (MA-Id) zu holen und in ungebundene Felder zu schreiben

Das macht man mit einer Abfrage und der Verknüpfung über die Schlüsselfelder viel eleganter und funktioniert auch in einem Endlosformular. Ich habe auch so gut wie noch nie mit Column(x) auf eine Kombifeldspalte verweisen müssen. Und VBA Lösungen sind immer weniger performant als das was man mit SQL (Abfrage) erledigen kann.

Ansonsten fällt es mir schwer Deinen Beiträgen zu folgen. Ist mir viel zu abstrakt.

[crystal]

Hallo Klaus,
Ich verstehe zwar nicht, was an meinen Beiträgen zu komplex wäre, aber da mag jeder eine andere Meinung haben.

Und allgemein:
Es ist immer wieder erstaunlich, wie in diesem Forum (und auch in anderen) Personen und deren Äußerungen, die nicht auf Mainstream-Linie liegen, von wenigen anderen, die sich als Pächter der Wahrheit verstehen, kritisiert, ins Lächerliche gezogen und mit erhobenem Zeigefinger abgetan werden. Dabei ist dies doch ein Diskussions-Forum, wo man auch mal andere Standpunkte haben können sollte, sei es nun aus Unwissenheit oder wegen eines anderen Erfahrungs-Horizonts.

Diskussion aber bedeutet für mich, sich mit den Thesen des anderen auseinander zu setzen und schlicht sachlich darzulegen, warum diese These nicht richtig ist oder sein kann. Und es bedeutet auch, Dinge sagen zu dürfen, die nicht zu 110% dem "Expertenwissen" entsprechen.

Es sollte ein Ziel sein, "falsche" Meinungen fachlich und sachlich zu kommentieren, um die Lösung des Problems voranzutreiben UND sowohl den Schreiber der "falschen" Meinung als auch andere dabei zu unterstützen, neue Erkenntnisse zu gewinnen, statt sie "von oben herab" zu kommentieren und dabei auch noch polemisch, provozierend, verächtlich und so weiter zu werden.

Ein schönes Beispiel für eine solche geradlinig zum Ziel führende, sachliche Diskussion ist mein Thread "Natürliche Sortierung", wie ich es darin auch geäußert habe.


Im Übrigen, lieber Klaus, bist auch du bisher eine konkrete Lösung des Themas schuldig geblieben. Bitte erstelle doch ein Formular, das dem Wunsch des TS entsprechen könnte, denn darum geht es doch vielen Fragestellern: wie mache ich das praktisch und so, dass es auch sinnvoll, einleuchtend, nachvollziehbar und einfach funktioniert, ohne dass ich zuvor ein Profi-Seminar absolvieren muss?

Im konkreten Fall reden wir von einer Anwendung, die eine begrenzte Lebensdauer von vielleicht ein paar Jahren haben wird, bis die Ausgabe der Handhelds vermutlich völlig anders gelöst oder nicht mehr erforderlich ist. Deshalb meine Idee, dem TS mit einem praktischen Beispiel einen Weg zu zeigen, statt ihn mit gebetsmühlenhafter Wiederholung die göttliche Notwendigkeit der Normalisierung einzutrichtern.

Ich bin Pragmatiker und stehe dazu, Lösungen zu entwickeln, die nicht für die Ewigkeit bestimmt sind, sondern um ein konkretes Problem zu lösen oder einen konkreten Wunsch zu erfüllen, ohne dabei jedoch einen Blick in die (nahe) Zukunft zu vergessen. Und ich weiß aus Erfahrung, wie kurzlebig manche wunderschönen, bis ins allerkleinste Detail während einer monatelangen Analyse wohl durchdachten Anwendungen im täglichen Proktionsablauf sind. Da reicht oft schon die Versetzung in eine andere Abteilung oder Mutter-(Vater-)schafts-Urlaub, manchmal sogar schon der Schichtwechsel.

In diesem Sinne...

crystal

[DF6GL]

Hallo,


ich bitte, solche ellenlange Ergüsse der eigenen Meinung, die vermutlich niemand interessieren , OT sind und auch den TS nicht sonderlich weiter zum Ziel bringen,  im Smalltalk-Board anzusiedeln und weiter zu führen...

Moderator

[Der_Schanko]

Hallo zusammen,

mir ist etwas andere Arbeit dazwischen gekommen, weshalb ich mich erst heute wieder mit der DB beschäftigen kann.

Ich versuche mal eure Diskussion hier nachzuvollziehen:
Ehrlich gesagt bin ich aber verwirrter, als ich es vielleicht vorher war.

ich will mich jetzt nicht sehr hier einmischen und den ganze Thread nachvollziehen, habe nur anhand des Beziehungsschemas keine durchgängige Logik erkannt. Soll heißen, was damit dargestellt werden soll, ist mir unklar.

Ich dachte ich hätte meine Tabellenstruktur jetzt soweit angepasst, dass ich mit der Erstellung von Formularen starten kann.
Wenn nicht, dann würde ich euch bitten mir nochmal detailliert zu bschreiben was denn falsch ist. Oder eine Anpssung in der von mir angehängten DB vorzunehmen, damit ich mir diese nochmal genau anschauen kann.

Die bisher vorgestellten Lösungen zeigen ja "nur" unterschiedliche Datenmodelle, aber keine Funktionalität.
Ich habe mir jetzt die letzte DB heruntergeladen und eine Tabelle und ein Formular hinzugefügt.

Das Formluar ist meiner eigenen Aufgabenstellung schon sehr nahe.
Sobald ich nachvollzogen habe, wie es funktioniert kann ich darauf aufbauen wohl weitere Formulare & Berichte erstellen.

Die zugrunde liegende Tabelle kann man dann zyklisch von alten Datensätzen befreien, ohne sich die Möglichkeit zu verbauen, zuvor andere Auswertungen in Form von Berichten und Statistiken, monatlicher Meldung an die Kostenkontrolle, Verlustmeldungen, Reparaturen usw. zu erstellen.

Das dachte ich mir auch, wäre super!
Danke hierfür schonmal.

allerdings unter Billigung von Redundanzen

Noch etwas zu den Redunundanzen, diese sind in jedem Fall in einem korrekten Datenmodell zu vermeiden.

Hierzu müsstet ihr mich noch einmal aufklären. Wo bestehen diese Redundanzen?

Im Moment hab ich mehr Fragezeichen im Kopf als Antworten...
Die einzige Lösung, die bis jetzt wirklich das abbildet, wie ich es mir vorgestellt habe kam von crystal.
Wie können die angesprochenen Redundanzen denn aufglöst werden?

Ich möchte auch nicht, dass hier nun eine Grundsatzdebatte ausbricht.
Ich dachte nicht, dass meine DB solch ein  umfangreiches Unterfangen wird.

Was mir fehlt um auch eigenständig probieren zu können ist ein klarer Ansatz für mich (gerne auch mit Erklärung warum).
Welche Tabelle nehme ich als Basis für mein Hauptformular in dem ich die Mitarbeitergruppen zur Gerätegruppe zuordnen kann.
Die eindeutige Beantwortung dieser Frage in Verbindung mir der "korrekten" Tabellenstruktur würde mir sehr weiterhelfen!

Vielen Dank für eure weiteren Antworten

LG
Schanko

[DF6GL]

Hallo,

damit wir von gleicher Situation ausgehen, lade die Db mal hier hoch, evtl. datenreduziert, komprimiert/repariert und gezippt.

[crystal]

Hallo Schanko,

vielen Dank für die Anerkennung meines Beitrags zu Lösung deines Problems bzw. Wunsches.

Um dir weiter helfen zu können, müsstest du bitte nochmal zusammenfassen, was du mit den Daten wie machen möchtest. Hierzu wäre es gut, wenn du kurz beschreiben würdest, welche Funtionalität du dir erwartest. Das Datenmodell als solches ist glaube ich schon sehr ausgereift, aber es bleiben eben Fragen zur Funktionalität.

Welche betrieblichen Abläufe möchtest du mit der Anwendung unterstützen? Bitte beschreibe diese Abläufe kurz und nenne die Informationen, die du dazu sehen möchtest, z.B. "Ausgabe eines Handhelds: Gerät auswählen, Name und Personalnummer des Ausleiers speichern, weitere Daten einsehen und ggf. speichern (Schicht, Schichtleiter, Kostenstelle...), Rückgabe-Zeitpunkt berechnen, usw.".

Dann kann man sich überlegen, wie diese Funktionen an der Oberfläche realisiert werden können und inwieweit es dabei möglich ist, Redundanzen (s.u.) zu vermeiden, ohne die Funktionalität einzuschränken.

Redundanzen sich schlicht Daten, die in einer DB mehrfach vorkommen. Wenn du eine Mitarbeiter-Tabelle hast und in der Geräte-Verbleib-Tabelle zusätzlich zur Personal-Nummer auch den Namen des Mitarbeiters speicherst (wie in meiner Beispiel-DB), ist eine Redundanz entstanden, denn auf den Namen könntest du ja auch über die Personal-Nummer zugreifen. Mein Beispiel zeigt also eindeutig, wie Redundanzen entstehen. Nach einiger Zeit steht in der Geräte-Verbleib-Tabelle der Name des MA Schulze mehrfach drin. In der "reinen Lehre" der Datenbank-Theorie ist das nicht erlaubt. Wenn man sich allerdings vor Augen führt, welchen Aufwand man treiben müsste, um diesen simplen Namen in Formularen darzustellen (man müsste ihn ja jedesmal aus der MA-Tabelle holen), muss man abwägen, ob man diesen Aufwand treiben möchte (z.B. mit viel VBA) oder die Redundanz schlicht akzeptiert, weil die Implementierung der Oberfläche dann erheblich einfacher ist.

Das eigentliche Problem von Redundanzen ist die Pflegbarkeit der Daten. Wenn sich der Name des MA z.B. ändert, wird er in der MA-Tabelle geändert, anhand der MA-Nummer. Aber was passiert in der Geräte-Verbleib-Tabelle? Nichts. Hier steht jetzt immernoch der alte Name drin und das kann natürlich zu Problemen führen.

Um das zu vermeiden, speichert man als in streng normalisierten relationalen Datenbanken grundsätzlich nur Referenzen auf die MA-Tabelle (Personal-Nummer) ab, denn so kann man jederzeit den aktuellen Namen bekommen.

Leider bieten Datenbansysteme kaum elegante Möglichkeiten, solche Referenzen an der Oberfläche zu de-referenzieren, also z.B. Name, Vorname etc. anhand der Personal-Nummer schnell und einfach zu holen und anzuzeigen. Natürlich geht das mit einfachen Select-Anweisungen, aber bei Access kommt nach meiner Erfahrung hinzu, dass es in Endlos-Formularen nicht immer gelingt, diese de-referenzierten Daten datensatz-abhängig darzustellen. Mag sein, dass ich hier falsch liege. Es bleibt aber die Tatsache, dass man eine solche De-Referenzierung für jeden aktuell darzustellenen Datensatz wiederholen muss. Und da denke ich als Pragmatiker: warum jedesmal und an allen Stellen wieder? und mache es lieber nur einmal und speichere die gewünschten Daten zusätzlich ab.

Lange Rede, kurzer Sinn. Ich wollte dich mit meiner Ausführlichkeit nur auf ein paar grundsätzliche Probleme bei der Entwicklung von Datenbank-Anwendungen hinweisen.

Grüsse,

crystal

PS an DF6GL:
Sorry, wenn dies wieder ein langer Text ist. Ich denke jedoch, dass er zum Verständnis beiträgt. Und ich habe niemand persönlich angegriffen, wie andere es mir gegenüber getan haben, was du vielleicht als Moderator auch bemängeln könntest...

[MzKlMu]

Hallo,
ich schließe mich der Bitte von Crystal an. Erläutere noch mal im Zusammenhang was Du in den Formularen darstellen willst. Ich habe da etwas den Überblick verloren und will das ganze Thema nicht noch mal lesen.

@crystal

Natürlich geht das mit einfachen Select-Anweisungen, aber bei Access kommt nach meiner Erfahrung hinzu, dass es in Endlos-Formularen nicht immer gelingt, diese de-referenzierten Daten datensatz-abhängig darzustellen. Mag sein, dass ich hier falsch liege.

Da liegst Du falsch, garantiert. Gerade in Endlosformularen ist eine Abfrage die die Mitarbeitertabelle einschließt zu bevorzugen. Mit der Verknüpfung über die Schlüsselfelder. Eine solche Abfrage ist die schnellste und sicherste aller Möglichkeiten. Auch bei Endlosformularen. Es ist auch nur ein einziges Select erforderlich. Es wäre auch zu bedenken, dass der Zugriff auf die Daten ohnehin immer über Abfragen erfolgen sollte und nicht über die Tabelle direkt, sodass man daher immer eine Abfrage braucht. Die Abfragen können als gespeicherte Abfragen vorliegen oder direkt als Select ... in der Datenherkunft eingetragen sein. Der Zugriff auf die Daten über die Tabelle ist langsamer als der Zugriff über eine Abfrage. Das mag bei wenigen Datensätzen nicht relevant sein, aber sobald große Datenmenge ins Spiel kommen, ist das zu beachten.
Ganz generell kann man sagen, überall wo möglich SQL verwenden, das ist die Sprache zur Datenmanipulation in Datenbanken.

Und ich habe niemand persönlich angegriffen, wie andere es mir gegenüber getan haben,

Ich lege Wert auf die Feststellung, dass ich mich da nicht angesprochen fühle.

[crystal]

Danke Klaus

für deine Hinweise. Ich bin ja durchaus lernfähig und offen für neue Erkenntnisse.

Vielleicht kommen wir gemeinsam einer Lösung näher und ich will gerne probieren, wie die De-Refenzierung "ad-hoc" an der Oberfläche per SQL besser funktioniert.

Aber jetzt ist erstmal Schanko gefragt (und gefordert).

Absolutes OK zu deinem Nachsatz.

Bis dann,

crystal

[Der_Schanko]

Hallo zusammen,

im Moment habe ich echt viel um die Ohren, komme kaum noch zur Weiterentwicklung der DB.

Redundanzen sich schlicht Daten[...]

Gut, das habe ich soweit verstanden. Dann wollen wir uns mal an die Lösung des Problems machen.
Bzw. ich versuche euch nocheinmal die gewünschte Funktionalität zu beschreiben.
Ich werde mich zunächst ausschließlich auf das "Hauptformular" beschränken, da es am dringensten benötigt wird!

Auslöser meiner ganzen Arbeit war, dass unsere Schichtleiter mit der alten Lösung nicht mehr zufrieden waren.
Zu viel manueller Aufwand etc.
Den Aufbau fanden sie aber sehr gut, bzw. haben sich daran gewöhnt und möchten die Möglichkeiten auch gerne beibehalten.
Im Anhang 1 seht ihr das ursprüngliche Formular.
Eine Tabellenstruktur zu der Datei kann ich euch nicht geben, weil es keine gibt.
Ich weiß nicht wie und ob das geht, aber unter "Beziehungen" wird nichts angeziegt. Auch wenn ich mir alle anzeigen lasse...

Ich möchte nun zur Funktionalität kommen. Diese ist in groben Zügen schon im "alten Formular" ersichtlich.
Hintergrund:

• Im operativen Betrieb arbeiten unsere Mitarbeiter immer mit jeweils einem Handheld (als portabler Computer) und einem mobilen Drucker (Etikettendrucker usw.)
• Ein Gerätepaar (Handheld + Drucker) wird IMMER

[MzKlMu]

Hallo,

•Ein Gerätepaar (Handheld + Drucker) wird IMMER

was ?