Office: (Office 2003) Wann Requery bei Register mit UFos einsetzen

Hallo allerseits,

ich kämpfe derzeit mit der Überarbeitung einer Access-Anwendung.

Dabei fliegt viel unnötiger Ballast raus und Fehler sollen weitgehendst ausgemerzt werden. In der Datenbank gab es einige grundsätzliche Fehler (unnötige Splittung einer Tabelle in 2 verschiedene Tabellen mit jeweils eigenen Autowerten inkl. der Folgeprobleme mit fehlenden Daten in der jeweils anderen Tabelle bzw. beim Synchronisieren beider zugehörigen Unterformulare), die ich nun bereinigt habe.

Was mich derzeit noch beschäftigt habe ich zwar in einem anderen Thema schon angerissen (http://www.ms-office-forum.net/forum....php?t=318539), aber ich stelle mir gerade eine grundsätzliche Frage:
Auf einem Formular mit Register und mehreren eingebunden Unterformularen werden Datensätze als unterschiedliche Zeilen angelegt, wenn man ein Kontrollkästchen als erstes anhakt.
Jetzt habe ich mir überlegt, dass ein Requery beim jeweiligen Verlassen des Unterformulars dieses Problem lösen könnte.
Mein erster Ansatz war also, beim Fokusverlust des jeweiligen UFos ein Requery abzusetzen.
Leider greift das nicht, wie ich es mir erhofft hatte.

Daher eine eher grundsätzliche Frage:
Wenn ein Formular mit Registern bearbeitet wird und der Anwender auf den nächsten Reiter klickt (also das nächste Unterformular anschaut) - wo müsste der Requery ansetzen bzw. welchen Status hat das Unterformular:
Fokusverlust,
Entladen,
Schließen,
Nach Aktualisierung,
Bei Geändert,
Bei Datenänderung
oder etwas ganz anderes?

Wer kann mir erklären, welchen Status ein Unterformular auf einem Register hat, wenn es zum Nächsten weiter geht?

Und falls mein Ansatz richtig wäre, reicht folgender Code aus (wenn man mal davon absieht, dass ich die richtige Aktion "erwischt" habe):
Code:

Derzeit habe ich zwar diesen Code in den Unterformularen eingepflegt, aber entweder ist das Ereignis falsch oder Code:

greift nicht...

Wie immer bin ich für jeden Tipp dankbar!

:)

 

Hallo zusammen,

kann mir denn niemand, welchen Status Unterformulare auf Registern in einem Formular haben?

Werden sie alle gleich als geöffnet deklariert, verlieren sie den Fokus, wenn man auf den nächsten Reiter klickt, etc.?

 

Hallo Norbert,

Vorschlag:
Häng doch mal in verschiedene Ereigniseigenschaften des Unterformularsteuerelements und des Unterformulars eine MsgBox rein, in etwa so:
Code:

Dann siehst du, wann sich was tut.
Wäre das eine Lösung ?

Gruß Josef

 

Wenn Du mir noch erklären kannst welches Problem Du meinst?
Was soll der Requery bewirken, wurden Daten geändert?
Werden die Unterformulare beim Klicken des Kontrollkästchens neu mit Daten versorgt?
Ich versteh es noch nicht ganz, glaube kaum dass das Ereignis Dein Problem ist.

 

Hi,
Aus der holen Hand
Es gibt noch ein Change-Value Ereignis bei dem Registersteuerelement, vor dem Sprung in einen neuen Tab.
Das hat bei mir geholfen.
Carsten

 

Ein Unterformular ist auch auf einem Registerblatt ein Unterformular und somit direkt Steuerelement des Hauptformulares. Also keine Änderung zum Normalzustand.

Code:

Das halte ich für Unsinn, die meisten Fokus-Setzereien sowieso.
Das Requery ruft die Datenherkunft neu ab und zeigt den aktuellen Stand im Formular an. Wo kämen jetzt Änderungen in der Tabelle her? In einem gebundenen Formular gibt man Änderungen ins Formular ein. Somit ist dieses aktuell, und die Änderungen müssten nachfolgend noch in der Tabelle gespeichert werden. Wohl kaum anders herum.

Allgemein: Wenn man über Formulare und Unterformulare spricht, ist eine Vorstellung darüber ohne die Angaben, ob die einzelnen Formulare gebunden sind oder nicht und welche Abhängigkeiten untereinander bestehen, nicht möglich und artet in ein Rätselraten (oder Schweigen) aus.

 

Hallo Eberhard,

ich vermute das Problem entsteht dadurch, dass beim Anlagen eines Datensatzes über das Formular sämtliche eingebundenen UFos geladen werden (Datenquelle für alle UFos = 1 Tabelle). Wenn dann die fraglichen Kontrollkästchen angeklickt werden ohne sonstige Werte zu erfassen, werden jeweils neue Zeilen angelegt.
Werden aber Werte eingetragen klappt alles. Daher meine Idee, mit jedem Wechsel auf ein neues UFo einen Requery abzusetzen, damit die restlichen UFos die Änderungen am Datensatz mitbekommen.

Eleganter wäre es natürlich, wenn die UFos erst dann ihre Daten aus der Tabelle beziehen, wenn man sie anschaut.

Ich hab das Ganze jetzt dann doch in eine Test-Datenbank gepackt (wenn einzelne Buttons nicht funktionieren liegt das daran, dass ich viele Formulare und Funktionen rausgeschmissen habe, um das ganze zu verschlanken. Dennoch hat die gezippte DB 557k; daher der Download über meine private Homepage:
http://www.nobby-ka.de/download/TestFrontend.zip

Beim Start der Datenbank öffnet sich das Hauptformular (mit einer Fehlermeldung wegen einem fehlenden Objekt (einfach weiterklicken)). Auf der Registerkarte Objekt findet Ihr oben einen Play-Button, der das Prüfformular startet, das den Fehler verursacht...

Ich habe Frontend und Backend vereint; in der Datenbank habe ich 2 Firmen angelegt.
Bei der ersten ist alles so, wie es sein sollte; bei der zweiten habe ich beim ersten Objekt den Fehler provoziert. In der Tabelle Objekt_BM findet Ihr das Resultat (Zeile 2 passt noch, die Inhalte der Zeilen 3-6 sollten eigentlich in der Zeile 2 stehen).

Ich freue mich über Eure konstruktiven Vorschläge!

Falls Ihr den Fehler bzw. die Lösung findet, bitte ich um eine kurze Erklärung, da ich ja nicht stumpf funktionierenden Code übernehmen möchte, sondern etwas dazulernen...

Danke!

 

Hallo Carsten,

das habe ich probiert (Ereignis beim Anklicken des Registers); bringt aber auch leider keine Verbesserung...

 

Diesen "Play-Button" habe ich nicht gefunden.
Bitte bedenke: Du sprichst Personen an, die durchaus einfach denken (nur so hat man Luft, dann auch an schwierige Aufgaben zu gehen).

In einer Demo würde ich NUR das relevante Formular mit den notwendigen Tabellen, Abfragen und Codes erwarten. Klar macht das Arbeit. Für den Fragesteller.
Aber es ist auch gezeigte Höflichkeit und Achtung vor der Zeit derjenigen, die man um Hilfe fragt, wenn sich jene das Problem unmittelbar anschauen können und sich dann nicht irgendwie durchwurschteln müssen.

Allgemeine Bemerkung: Die Kontrollkästchen-Tiraden in Formular und dann auch in der zugrundeliegenden Tabelle sind fürchterlich. Beispiel aus Tabellendefinition:
Code:

Wenn man da unabhängig Werte verändern kann: Welche Schlussfolgerungen kann man daraus ableiten?

Wenn Du codemäßig da Abhängigkeiten hinterlegen willst, ist es für mich nur logisch, dass man da recht schnell auf die Nase fällt.

Hast Du schon einmal Optionsgruppen gesehen?

 

Frage: Wieso gibt es in der DB keine einzige Relation zwischen den Tabellen?
Sind die durch die Erstellung der Testdatei rausgefallen?
Ansonsten muss ich mich Eberhard anschließen; ich kann nicht ganz folgen was hier passieren soll... den Play-Button suche ich auch vergeblich.

 

Hallo Eberhard, hallo Benny,

zunächst einmal danke für's Anschauen.

Ich habe die Test-DB rudimentär zusammengezimmert. Daher die fehlenden Relationen.
Die Datenbank beinhaltet auch nur das Notwendigste, um ohne Fehlermeldungen testen zu können. Da die Objekte nur im Bezug auf das Hauptformular sauber anzusprechen sind, ging's nicht wirklich schlanker; sorry dafür!

Zum Sinn (oder Unsinn) mancher Fragen: Da lässt sich leider nichts ändern / optimieren. Das sind Vorgaben, die vom VdS und den Versicherern ausgehandelt wurden. Das muss so sein.

Und nun zum Play-Button:
Die Registerkarte Objekt beinhaltet ein zweiteiliges UFo. Oben ist die Listenansicht der Objekte, unten die objektspezifischen Fragen dazu.
Oben in der Liste ist ganz links (direkt neben dem jeweiligen Datensatzmarkierer ein Play-Button, der mit Bezug zum Sachgebiet das passende Formular aufruft. In dem Fall Pruefung_BM.
Sorry, wenn ich mich da zu unverständlich ausgedrückt hatte.

Wie gesagt auf Gesamtkonzept und insbesondere die Fragen auf den Formularen habe ich leider keinen Einfluss. Das sind feste Vorgaben...

 

Hallo,

dann könntest Du die DB glatt entsorgen. Das Datenmodell ist bereits grundlegend falsch. Alleine die vielen Ja/Nein sind in der vorliegenden Verwendung für ein Datenbank unbrauchbar. Hier fehlen noch Tabellen.
Ich glaube auch nicht, dass Eberhard die Fragen an sich bemängelt, sondern die Art und Weise wie man das in der DB handhabt. Die Fragen sollten Feldinhalte sein (in einer Fragentabelle) und keine Feldnamen.
Z.B. für die Messgeräte.
"Unitest - Zangenamperemeter CHB130 / BEHA - AC Clamp Meter"
Als Feldname ist das eine Katastrophe. Das sollte ein Feldinhalt sein in einer Tabelle für die Messgeräte. Die Ja/Nein Felder würden dann für die Messgeräte entfallen. Das gilt sinngemäß auch für alle anderen Ja/Nein Felder.

Auch von mir die Frage, warum sind keine Beziehungen angelegt ?
Eine Datenbank ohne Beziehungen ist mehr als bedenklich.

Zu den Ja/Nein Feldern:
Microsoft Access Tips for Casual Users
Wenn man den Regeln folgend die Ja/Nein Felder in korrekte n:m Beziehungen auflössen will, so fehlen dann noch 26 Tabellen (ja, 26 !)
13 Gruppen Ja/Nein Felder mit je einer Tabelle und 13 Zuordnungstabellen für die n:m Beziehungen.
Kann sich auch noch etwas reduzieren, da man möglicherweise auch Optionsgruppen verwenden kann.

Wenn Du wirklich konsequent sein willst (mit der Fehlerbeseitigung) , kannst Du von dieser DB so gut wie nichts verwenden, noch nicht mal die Formulare.


Übrigens, die Splittung in 2 Tabellen (bei der jetzigen/falschen Struktur), war auch nicht unnötig, sondern erforderlich weil eine Tabelle nur max. 255 Spalten haben kann. Noch ein Grund das bisherigen Konzept komplett über den Haufen zu werfen.

 

Hallo Klaus,

die Relationen zwischen den Tabellen gibt es im Original. Wie ich bereits erklärt hatte, fehlen diese in der Beispieldatenbank, in die ich die Tabellen und Formulare einfach importiert habe.

Komplett Neumachen wäre zwar schick und es ließe sich sicherlich viel optimieren, aber meine Unterstützung wurde angefordert, um u.a. Fehlermeldungen bzw. wirkliche Fehler bei Ein- und Ausgabe auszumerzen. Da das Ganze als Freundschaftsdienst läuft, möchte ich hier auch keine Monate investieren.

Ich sehe es als eine Möglichkeit mein Access-Wissen zu vertiefen und freue mich, wenn unterm Strich die DB hinterher zumindest ein bisschen besser ist.

Mit den "Altlasten" kann und muss ich also leben.

 

Hallo,
ich habe in #12 noch was nachgetragen (letzter Absatz).
Die 2 Tabellen wirst Du also schon mal nicht ändern können, wenn Du das Konzept so beibehältst.

 

Hallo zusammen,

hier ein Screenshot der Beziehungen in der echten Datenbank: