Hallo,
ich knoble schon viele Stunden an einem Problem:
Ein Bericht wird dynamisch aus einer komplexen Abfrage erstellt. Der Bericht selbst wird augenblicklich erstellt, die Erstellung der Datenfelder im Berichtskopf und Detailbereich (ca. 150 Felder) dauert sehr lange (15 Minuten.
Wenn ich die Erstellung beobachte, werden die ersten Felder relativ schnell erstellt (ca. 1 Sek. am Anfang), die erforderliche Zeit wird immer länger und reicht bis zu 15 Minuten für die letzten Felder.
Wenn der Bericht fertig erstellt ist, funktioniert die Befüllung ganz normal. Bei auch nur einer kleinen Änderung in der Struktur (per Code oder manuell) dauert der Vollzug der Änderung wieder mehrere Minuten.
Kann mir jemand erkären, wie es zu diesem Phänomen kommt und wie mas dieses ev. verhindern kann?
Gruß Michael
Hallo,
es ist völlig ungewöhnlich dass ein Bericht zur Laufzeit erstellt wird. Im Regelfall hat man einen fertig angelegten Bericht, der mit einer Abfrage mit den Daten versorgt wird.
Daher glaube ich, dass zu dem Phänomen nur sehr wenig Erfahrung besteht, weil es so nicht prktiziert wird.
Hallo,
wenn Du dazu immer den gleichen Report verwendest, wird Access irgendwann das Anlegen neuer Controls verhindern.
Wenn Du unbedingt einen dynamischen Report brauchst, lege die 150 Felder gleich zu Beginn an (verwende dazu erst mal einen neuen Bericht) und setze sie dann per VBA auf unsichtbar (einmalig). Die Felder sollten einfach durchnumeriert sein, um sie schneller in einert Schleife ansprechen zu können.
Dann kannst Du die Felder anhand der Abfrage passend verteilen und sichtbar machen, die unsichtbaren stören dann nicht, wenn sie keine ControlSource haben.
Das Sichtbarmachen und Verteilen der Controls geht unendlich oft. Das Neuerstellen von Controls nicht, das sollte grundsätzlich nur bei Programmierung von Developertools verwendet werden. In einer Enduser-Datenbank sollte nie per Design die Datenbankdatei angepaßt werden (und wenn man die Access Runtime verwendet, ist es nicht einmal möglich).
Das ganze muß in Report_Open gemacht werden.
Die Methode funktioniert in Formularen, in Access-Reports habe ich das selbst noch nie gemacht, mußt Du ausprobieren.
Es sollte jedenfalls immer ohne merkliche Zeitverzögerung funktionieren.
Gruß
Christian
Hallo Michael,
letztens hatten wir schon mal ein ähnliches Problem mit dynamisch erstellten Formularen. Beides, sowohl für Formulare als auch für Reports, wird in Access nur, wenn überhaupt, während der Entwicklungsphase eingesetzt, keineswegs zur Laufzeit. Man kennt so etwas von anderen Entwicklungstools und Programmiersprachen, in Access wäre das der falsche Ansatz, weil das in einer *.accde und unter der Runtime sowieso nicht unterstützt wird.
Hier solltest du dir einen andere Workflow überlegen oder auf andere Reportings-Tools ausweichen, die so etwas unterstützen.
Knobbi38
Vielen Dank für die Tipps!
Das Anlegen eines Berichts mit möglichst allen ev. vorkommenden Feldern und der Zuweisung der erforderlichen Eigenschaften (vor allem Controlsource) zur Laufzeit löst mein Problem.
Jetzt ist mir noch ein Problem aufgefallen: Wenn ich im Entwurfsmodus während der Entwicklungsphase einzelne Eigenschaften ausgewählter Controls ändere, dauert der Restore recht lange (bis zu 10 Minuten), egal ob ich die Änderung manuell im Entwurf oder per Code in einer Prozedur vornehme.
Kennt jemand eine Lösung, ob man diesen Prozess beschleunigen kann?
Herzliche Grüße Michael
Hallo,
wie gesagt, Du solltest nicht den bereits verwendeten Report nehmen, sondern einen neuen aufbauen.
Im Zweifelsfall den Report mit Application.SaveAsText und Application.LoadFromText in eine neue Datenbank laden, dann sollte es auch wieder normal schnell gehen.
10 Minuten sind ja indiskutabel.
Du könntest für einen Restore auch einfach eine Kopie des Reports verwenden. Das erspart Dir ein Restore. Im Entwurfsmodus solltest Du aber nie arbeiten müssen zur Laufzeit, das Verschieben und Ein-/Ausschalten oder Ändern der Controlsources geht alles bei normal geladenem Formular.
Gruß
Christian
Hallo Michael,
die Eigenschaften könntest du auch zur Laufzeit zuweisen bzw. ändern, was beim Refactoring sicherlich hilfreich sein dürfte.
Wenn du so einen komplexen Bericht hast, könntest du den auch ungebunden betreiben und dann ggf. mehrere Werte in einer Textbox mit RichText darstellen. Mit so einer Textbox können dann mehrere Werte z.B. in kommaseparierte Listen u.v.m. zur Anzeige gebracht werden. Die Formatierung solcher RichTexte wird dann einfach in speziellen Klassen ausgelagert.
Für das Zuweisen der Daten zur Laufzeit werden schlichtweg VBA Funktionen in den diversen Format-Ereignisroutinen verwendet, was auch bei vielen Daten noch relativ zügig läuft.
Gruß Knobbi38
Zitat von: huith am Juli 04, 2025, 18:48:43reicht bis zu 15 Minuten für die letzten Felder.
Hab auch schon öfter Mengen an Controls per Code erzeugt.
150 Controls mitsam Events per Code anlegen, dauert insgesamt unter 2 Sekunden.
Da würde ich das Problem ausserhalb von Access vermuten.
Installation aktuell?
Access Version von deiner Windows unterstütz?
Vierenscanner ?
Vielleicht mal System bereinigen und neu installieren.
Hallo Michael,
kannst du mal ein Beispiel zeigen wie so ein Bericht aussieht?
Tust du wirklich zur Laufzeit Controls erzeugen und positionieren?
Da hat Access gewisse Grenzen was die Anzahl Controls und auch die Geschwindigkeit angeht.
Eventuell wäre es ja eine Option, hier nicht Access zu verwenden, sondern eine dynamisch erzeugte HTML-Seite zu erstellen und diese in einem Webbrowser-Control anzuzeigen.
Ich hab das z.B. für eine Sport-Auswertung und Berichtsansicht gemacht. Das erstellen der HTML-Seite geht auch bei vielen Feldern ruck-zuck.
Hier hab ich das mal in Auszügen in meinem Block gezeigt:
http://accessblog.de/2024/11/05/mehrstufige-abhaengige-auswahl/
Gruß Andreas
Vielen Dank für die vielen Tipps; ich werde sie jetzt nach und nach ausprobieren, insbesondere die Berichtsausgabe als HTML-Seite scheint mir interessant.
Ich habe jetzt einige Formulare als Text gespeichert und in neue Formulare importiert mit durchschlagendem Erfolg.
Jetzt wollte ich das auch bei einigen Reports machen. Der Export funktioniert, aber beim Import in einen neuen Bericht erhalte ich die Fehlermeldung "kann die Datei 'rptTestbericht.txt' nicht öffnen, obwohl die Datei existiert und sich im Texteditor auch öffnen lässt.
Was mache ich da falsch?
Danke für Hinweise!
Hier noch ein anderes "Tool", wo HTML-Reports erzeugt werden:
https://sourceforge.net/projects/miraapt/ (https://sourceforge.net/projects/miraapt/)
oder:
https://vb123.com/extending-access-reports-with-word-and-html/ (https://vb123.com/extending-access-reports-with-word-and-html/)
alternativ könnte man auch Word als "Report-Tool" missbrauchen. ;)
Gruß Knobbi38
Hallo,
warum so kompliziert?
Am Naheliegendsten ist es doch, wenn man schon ein externes Report-Tool verwendet, Excel zu verwenden. Keine von Grund auf neue Technologie, dafür aber sehr gute Report-Möglichkeiten, von denen (leider) Access nur träumen kann.
Excel kann auch gleich selbst auf die Datenbank zugreifen und die Daten von z.B. einer dort formulierten Abfrage auslesen (oder in PowerQuery selbst erstellen).
Gruß
Christian
@christian:
ZitatAm Naheliegendsten ist es doch, wenn man schon ein externes Report-Tool verwendet, Excel zu verwenden.
Ich wäre eher auf Word gekommen, denn mit der Serienbrieffunktion lässt sich so etwas viel einfacher gestalten als mit Excel und ein Datenbankzugriff ist damit ebenfalls möglich.
Gruß Knobbi38
Hallo Ulrich,
habe ich vielleicht überlesen, aber wo stand denn was von Serienbriefen (Serienreports)?
Ich habe bislang nur verstanden, daß es um Berichte mit dynamischer Breite geht, also wechselnde Felder.
Es hängt natürlich von der Art des Reports ab, wenn es um textuelle Reports geht, kann man das sicher auch mit Word machen, aber bei grafischen Reports ist Word dann wohl eher keine gute Wahl (wobei man das natürlich auch mischen kann).
Gruß
Christian
@ Christian:
Wenn es um Diagramme geht, ist Excel sicherlich die bessere Wahl, aber davon war bisher nicht die Rede. Für Textsachen und dynamische Reports bietet sich Word geradezu an, weil alleine durch die Datenquelle die Felder bestimmt werden können und mit den Seriendruckfeldern das sehr flexibel gestaltet werden kann.
Grüße Ulrich