Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Alternative für Filter von Access bei Datenblattansicht

Begonnen von MarkusR, September 05, 2013, 07:49:05

⏪ vorheriges - nächstes ⏩

MarkusR

Guten Morgen zusammen,

ich bräuchte mal wieder Eure Hilfe  :)

Ich habe auf einem Formular ein Unterformular das in der Datenblattansicht angezeigt wird. Das Datenblatt hat 33 Spalten von den ich 16 Spalten in der Abfrage die als Quelle dient mit DAO berechne (vorher hatte ich das mit Dom Funktionen, das war aber viel zu langsam). Angezeigt werden in dem Datenblatt alle Bestellungen. Das sind zur Zeit ca. 4500 Datensätze, wobei jeden Monat zwischen 30 und 100 Datensätze dazu kommen werden. Testweise habe ich die Tabelle mit 3500 Datensätzen befüllt. Die Berechnungen für die Felder ist mit DAO kein Problem. Das Datenblatt öffnet sich sofort und es gibt keine Ladezeiten.

Das Problem ist jetzt, dass ich auf einmal ewig lange Ladezeiten bekomme, wenn ich den Filter von Access benutzen möchte. Und zwar kann man ja in der Datenblattansicht auf die Kopfzeile klicken um das Filtermenü aufzurufen. Jedoch dauert das ca. 70 Sekunden, bis sich das öffnet. Ich vermute mal, dass Access im Hintergrund irgendwelche doofe und langsamen Berechnungen macht.
Jetzt wollte ich Euch fragen, ob jemand eine Alternative dazu kennt? Muss ich da jetzt eigene Filter programmieren? Gefiltert werden ganz verschiedene Felder: mehrere Felder mit Datumangaben, einfache Zahlenfelder, Textfelder, Kontrollkästchen oder auch Felder mit Preisen, also Währungen).

Vielen Dank im Voraus für Hilfe und Anregungen  :)

Beste Grüße
Markus

DF6GL

#1
Hallo,

in einem solchen Fall ( ich frage jetzt nicht nach der Notwendigkeit so vieler berechneter und insgesamter Spalten in Datenblattansicht) wäre darüber nachzudenken, mit einer temporären Tabelle zu arbeiten, in die anfänglich sämtliche Daten, auch die berechneten, zunächst gespeichert werden und die Tabelle dann im Formular zur Anzeige zu bringen.

Die andere Möglichkeit, dem Formular jeweils einen mit dem akt. Filterkriterium versehenen SQL-String in seiner Datenherkunft zuzuweisen, sollte trotzdem erst getestet werden.
Viele Grüße vom Bodensee
Franz, DF6GL

Hilfestellung:  http://www.access-o-mania.de/forum/index.php?topic=6969.msg118738#msg118738

Links und Tipps:
1.   http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/
1a. http://www.tinohempel.de/info/info/datenbank/normalisierung.htm
1b. https://support.office.com/de-de/article/Grundlagen-des-Datenbankentwurfs-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5#bmterms
2.   http://www.donkarl.com
3.   https://web.archive.org/web/20201201233522/http://www.dbwiki.net/
4.   http://www.access-tutorial.de/
5.   http://www.tty1.net/smart-questions_de.htm
6.   http://access.joposol.com/accept

Last but not least:   < F1 > für Hilfe
;) Learning by doing not by spoon-feed ;)

Tipp: Find and Replace for Access

MarkusR

Hallo,

danke für Deine schnelle Antwort.

Hatte auch schon mal nachgedacht, eine Tabelle dafür zu erstellen. Kenn mich da aber noch nicht so gut aus. Ich würde also beim Öffnen des HF eine Abfrage ausführen, die alle Daten berechnet und in eine Tabelle schreibt. Diese Tabelle würde dann als Quelle für das Datenblatt dienen. So weit denke ich, würde ich das hinbekommen.
Jetzt stellt sich mir die Frage, was passiert, wenn ein Nutzer etwas an einem Datensatz der eigentlichen Daten ändert. Wie kommt die Änderung dann in diese Tabelle, damit es auch die anderen Nutzer sehen können?

Die Möglichkeit, die ich zuerst testen soll, verstehe ich grad nicht. Was meinst Du mit "mit dem akt. Filterkriterium versehenen SQL-String"?

DF6GL

Hallo,

Die Lösung 1 zeigt natürlich  nur den Daten-Sachverhalt zu dem Zeitpunkt, an dem die Temp-Tabelle gefüllt wird.


Lösung 2 bedeutet, entspr. der gewünschten Filterung mittels VBA eine Where-Condition zusammenzubauen und dem "rohen"  (Abfrage mit Berechungen , aber ohne jegliche Kriterien-Angaben) Formular-Abfrage-SQL-String anzuhängen . Dieses Konstrukt wird dann der Datenherkunft des Forms zugewiesen, wodurch dem Formular schon "gefilterte" Daten geliefert werden und eben diese anzeigt.


Viele Grüße vom Bodensee
Franz, DF6GL

Hilfestellung:  http://www.access-o-mania.de/forum/index.php?topic=6969.msg118738#msg118738

Links und Tipps:
1.   http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/
1a. http://www.tinohempel.de/info/info/datenbank/normalisierung.htm
1b. https://support.office.com/de-de/article/Grundlagen-des-Datenbankentwurfs-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5#bmterms
2.   http://www.donkarl.com
3.   https://web.archive.org/web/20201201233522/http://www.dbwiki.net/
4.   http://www.access-tutorial.de/
5.   http://www.tty1.net/smart-questions_de.htm
6.   http://access.joposol.com/accept

Last but not least:   < F1 > für Hilfe
;) Learning by doing not by spoon-feed ;)

Tipp: Find and Replace for Access

MarkusR

Hey,

ne, dann kommt Lösung zwei eher nicht  in Frage. Denn hier würde man ja quasi das Kontextmenü der Kopfleiste umgehen. Eben diese brauche ich aber.

Habe mir jetzt ein bisschen zu Lösung 1 überlegt. Werd dann im Formular nach Aktualisierung die temporäre Tabelle für das Datenblatt löschen, neu erstellen und befüllen. Dann sollte das ja eigentlich funktionieren.

Mal wieder Danke für Deine Hilfer!!!