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

Der Thementitel lautet:

Ich frage mal im Gegenzug: Wozu soll ein Requery dienen?

- Wie oben schon gesagt (bin immer noch der gleichen Meinung): Wenn Du etwas in ein gebundenes Formular einträgst, ist das Formular aktueller als die dahinterliegende Tabelle (bis zum Zeitpunkt des Datensatz-Speicherns).

- Ein Datensatz-Speichern erfolgt, wenn nicht explizit aufgerufen, mit dem Verlassen des Datensatzes (Datensatzwechsel, Formularwechsel, Schließen Formular oder gar Anwendung).

- Deine 5 Unterformulare haben alle als Datenherkunft die gleiche Tabelle. Falls mehrere UFo's gleiche Felder verwenden, müssten ggf. die anderen (betreffenden) Unterformulare aktualisiert werden, nicht das aktive.
Idealerweise reduziert man das auf jeweils sichtbare Formulare, erst da macht es ja zur Ansicht Sinn.

- Zum Erkennen, welches Registerblatt aktuell sichtbar ist (inklusive dem darauf liegenden UFo), kann man wie bereits genannt das Change-Ereignis der Registerobjektes nutzen, siehe auch Register - Seitenwechsel-Ereignis

Das verstehe ich nicht wirklich. Welches KK aus dieser Vielfalt?

Wenn natürlich in jedem der UFo's die Möglichkeit besteht, einen neuen Datensatz anzulegen, können in der Tabelle Informationen auf mehrere Datensätze zergliedert werden.

Da sage ich mal ketzerisch: Wenn diese Art der Datenspeicherung und dieses Formulardesign vorgeschrieben sind, sollte man auch gleich eine Anleitung von gleicher Stelle erwarten dürfen, wie dann solche Formulare funktionieren.

 

ist wohl eher ein Gesamtchaos. Kann nur Eberhard zustimmen: fordere eine Anleitung an.
Selten so etwas grausiges wie auf dem Bildchen mit den Beziehungen gesehen...

 

Hallo Eberhard, hallo Elmar,

klar ist das keine tolle Ausgangssituation. Aber diese komplexe Datenbank neu zu entwickeln würde wohl Monate dauern und dafür ist bei einem Freundschaftsdienst bei aller Liebe kein Platz...

Der Fehler passiert ja explizit bei der Eingabe bei Brandmeldeberichten. Ich habe mal versucht, das Ganze anhand von Screenshots verständlicher zu machen:

 

Der Screenshot01 zeigt den Aufruf des Prüfformulars (den ominösen Play-Button).

Die Screenshots02 bis 05 zeigen das vermaledeite Ja-/Nein-Kästchen, das die Probleme verursacht.

Erfasst ein Sachverständiger im Formular zuerst einmal alle Seiten, die er im Bericht benötigt ohne zuvor die echten Prüfdaten auf dem Formular zu erfassen, wird in der Tabelle je Unterformular eine Zeile angelegt:

 

Daher liegt der Verdacht nahe, dass das Formular aktueller als der Datensatz in der Tabelle ist.

Um dieses Problem zu lösen, dachte ich an den Requery-Aufruf.

Mir sind aber auch alle anderen Lösungsansätze recht, wenn ich meinen Freunden dadurch helfen kann.

Wie kann ich es bewerkstelligen, dass nach einer Eingabe in dem Ja-/Nein-Feld der Wert in die Datenbank eingetragen wird und das aktuelle und die weiteren Unterformulare neu mit den Tabellendaten befüllt werden?

Das Problem (also dieses spezifische) in der Anwendung habe ich ja erfasst; aber wo setze ich an, um es zu vermeiden?

Der damalige Entwickler scherte sich übrigens nicht um die Belange der Anwender; wie mir gerade telefonisch mitgeteilt wurde, war seine Aussage zur Bedienung der Datenbank bzw. bei auftretenden Problemen: "Dann benutzt das Programm halt richtig!"

Auch wenn Eure Hilfestellung eine katastrophale Anwendung mit Konzeptionsfehlern (für die der Entwickler wohl nicht immer was dafür kann - wir alle kennen die teils unsinnigen Normen von Fachinstituten) wohl im Gesamten nur ein Tropfen auf den heißen Stein wäre, bitte ich Euch um Eure weitere Unterstützung, damit ich hier helfen kann.

Für mich ist es ein Non-Profit-Job, aber es würde mich ärgern, wenn es nicht möglich ist, den Fehler zu beheben...

PS: Bevor ich hier angefangen habe zu helfen hatte die Anwendung sage und schreibe 26 Registerkarten auf dem Hauptformular; das Meiste konnte ich durch das Anlegen eigener Prüfformulare (die, die mit dem play-Button geöffnet werden) entrümpeln.
Bei manchen Sachgebieten gab es bis zu 12 Druck-Buttons für einzelne Berichte, die dann später zu einem Bericht zusammengefasst wurden. Dies habe ich erfolgreich umgestellt auf einen Button pro Sachgebiet, nach dessen Klick ein fertiges PDF mit richtigem Namen im jeweiligen Kundenordner gespeichert wird.
Es ist also durchaus möglich, so etwas Grottenschlechtes anwenderfreundlich umzugestalten.

 

Lieber Norbert,
ich habe es mir mal angetan und Die DB genauer angeschaut (ich hätte es wohl besser bleiben lassen).
Ich kann nur alles bestätigen was bereits gesagt und bemängelt wurde.
Der Aufwand die DB "Instandzusetzen" kommt einer Neuentwicklung gleich.
Daher schließe ich mich Klaus Empfehlung an

Der Aufwand ist die Mühe nicht Wert.

 

Ich kann mich des Eindrucks nicht erwaehren, dass Du den INHALT von oben gemachten Aussagen nicht erfassen willst. Das Feedback ist gemessen an fachlichen Hinweisen kläglich.

Eine wiederholte Tatsachenfeststellung immerhin als Verdacht anzuerkennen, ist ein bedeutsamer Schritt, wenn auch ein seeeehr kleiner.

Wie kann man einen bearbeiteten Datensatz speichern? Einfach durch ein ...
Code:

Das aktuelle Formular muss nicht aktualisiert werden, weil eben schon aktuell.

Die anderen Formulare wären dann durch ein Requery in den aktuellen Stand der Tabelle zu erheben, nach dem Speichern im aktuellen Formular.
Das ganze besser nicht umfassend für alle, weil ja ein Neuabrufen der Datenherkunft jeweils eine Abfrage ist und zeitlichen Aufwand bedeutet, besonders dann bei umfangreichen Daten und schlecht designten Abfragen.

Insgesamt möchte man hoffen, dass es zwischen diesen Unterformularen keine zusätzlichen Abhängigkeiten untereinander außer der gemeinsamen Datenherkunft gibt.

Man kann die Bedienung auch steuern, indem man das sperrt, was noch nicht dran ist mit ausfüllen.

 

Ach so, Deine ummalten Kontrollkästchen sind so, wie sie sind, einfach Kacke. Einfach schon mal deswegen, weil eine Eingabe von Daten und eine spätere Druckausgabe erst einmal nichts miteinander zu tun haben (sollten). Man muss nur überwachen, dass nur vollständige Eingaben auch ausgedruckt werden können.

Wie Du in diesem Thema schon hättest lesen (oder vorher schon selber wissen) können, wird beim Verlassen eines Datensatzes (oder Formulares) der Datensatz gespeichert. Die KK sind ebenfalls gebunden an Felder der Tabelle.

Da die Unterformulare die gleiche Dabelle als Datenherkunft haben und quasi in Summe einen Datensatz darstellen (darauf muss man erst einmal kommen), müsste bei einem Wechsel eine Synchronisierung auf genau den gleichen Datensatz erfolgen. Das erfolgt nicht. Daher wird jedes neu fokussierte UFo bei einer beliebigen Eingabe einen neuen Datensatz anfangen, sprich Autowert bei ID fortsetzen. Ersatzweise könnte man AllowAdditions konsequent deaktivieren.

 

Hallo Eberhardt,

danke!

Sorry, wenn ich etwas beratungsresistent erscheine; ich denke aber, das ist der Tatsache geschuldet, dass wir aneinander "vorbeischreiben".

Noch eine klitzekleine Frage:
Das Ereignis für Code:

wäre dann bei beim jeweiligen Unterformular Nach Eingabe, Nach Aktualisierung oder Bei Geändert?

Ich dachte immer ein Requery würde nicht nur neu laden, sondern auch die Tabelle(n) aktualiseren...*idee

Genau darin liegt eines der Probleme dieser exotischen Anwendung: Keiner der Ingenieure konnte mir für keine Seite des Berichts bzw. für keines der Formulare einen verbindlichen Wert verraten, den er bei seinen Prüfungen erfasst, woraufhin die Seite dann eben ausgedruckt werden soll oder nicht. Ich denke also, die Verwendung dieser Kästchen beruht auf den unklaren Vorgaben, die der Erschaffer dieser Anwendung hatte...

Hallo truethworthy,

würde ich ja gerne tun; warum das nicht geht, habe ich zuvor ja erklärt...

Und das Fatale ist: Das "Dingens" (Datenbank mag ich's gar nicht mehr nennen) läuft seit vielen Jahren bereits produktiv und die Datenmenge darin ist enorm.
Und analog zur derzeitigen "Geiz ist Geil"-Mentalität sieht das Unternehmen keinen Handlungsbedarf für eine Neufassung...

 

Ja der Glaube ...
Wodurch kann eine Tabelle aktualisiert werden? Durch einen Speichernvorgang.
Und zum xxx. Male: Durch Formularwechsel erfolgt ein automatisches Speichern durch Access.
Ein explizites Speichern wäre dann nötig, wenn z.B. unmittelbar auf eine Formulareingabe mit Buttonklick vom Formular ein Berichtsdruck erfolgen soll, der die vollständigen Daten enthalten soll.

Ich für meinen Teil kann das umgehend ändern in "nicht schreiben".

 

Hallo Eberhard,

ich weiß zwar nicht, wodurch ich Dich so verstimmt habe:

Aber dennoch danke ich Dir, da der
Code:

das Problem gelöst hat.