Hallo,
Ihr macht mich fertig! *grins*
I Wo , Du machst Dich selber fertig mit deinen Überlegungen 
Also, das mit einer Tabelle sorgt bei mir einbisschen für
Bauchschmerzen. Werde es mir aber zur Brust nehmen und
umsetzen (auch wenn ich es eigentlich nicht möchte).
glaube uns, es IST besser.
Mit SQL meinte ich natürlich den Einsatz von SQL-Server, wie
Franz richtig vermutet hatte.
ok, tut aber weiter nichts zur Sache.
Dass bei jedem Vor und zurück Navigieren im Formular oder
Suchen die Formularabfrage von Access selbstständig
aktualisiert wird, halte ich für ein Gerücht.
NEIN, das ist KEIN Gerücht.
Das hatte ich
nämlich ausprobiert und es geht nicht.
Du interpretierst etwas falsch: Speichern in eine Tabell und das Anzeigen des Tabelleninhaltes sind zwei Paar Stiefel.
Daten die am
Arbeitsplatz1 (AP1) über das Formular erfasst wurden, können
nicht auf dem Arbeitsplatz2 (AP2) eingesehen werden, wenn das
Formular bereits vor dem Abspeichern am AP1 geöffnet wurde.
Stimmt nicht.
Hierzu hatte ich bereits das Me.REQUERY eingebaut, welches mir
bei bestimmten Aktionen im Formular die Abfrage aktualisiert.
WO hast Du das eingebaut? Bei welchen „Aktionen“ (falls Du damit Ereignisse meinst)?
Soweit ich es gelernt habe, wird mit dem Öffnen von Abfragen
eine temporäre Abfragetabelle geöffnet (Formularabfragen sind
auch nur Abfragen).
WO öffnest Du denn Abfragen (hier in den Beispielen)?
In dieser werden dann die Änderungen
erfasst und zugleich in die „richtige“ Tabelle erfasst. Es
erfolgt dabei aber kein Abgleich zw. der richtigen Tabelle und
der temporären Abfragetabelle.
??? ist unverständlich.
Wodurch geänderte Datensätze
von anderen Abfrage-„Aktionen“ nicht in meiner temporären
Abfragetabelle erscheinen.
???
Hierzu muss ein Requery erfolgen
und dies erfolgt nach meinem mir beigerachten Wissenstand über
das schliessen und öffnen der temporären Abfragetabelle.
In den Access-Optionen gibt es eine Eigenschaft „Aktualisierungsintervall“. Das bestimmt den Aktualisierungsabstand z. B. in einer Abfrageansicht oder auch des Formulares, wenn Daten in der enstpr. Tabelle von woanders aus geändert wurden. (Betrifft NICHT neu in die Tabelle eingefügte Datensätze.
Das
geht schneller als der Vergleich von vorhandenen und nicht
vorhandenen Datensätzen (hab ich, hab ich nicht, hab ich, hab
ich, hab ich nicht) in meiner Abfragetabelle.
??? verstehe ich nicht. Was bedeutet „Vergleich“
Da ich aber bei der Verwendung von „vielen“ einzel Tabellen
keinen Filter auf die Tabelle anwenden muß geht das Neuöffnen
der Abfragetabelle schneller, als wenn ich eine Tabelle habe
und erst den Filtern drüberlegen muß.
Stimmt nicht. Das Filtern einer Tabelle (—> Angabe von Kriterien in einer Abfrage) hängt vom Aufbau der Tabelle und dem „Filteroperator“ ab. D. H. Felder, nach denen gefiltert wird ( auf die ein Kriterium angesetzt wird) sollten indiziert sein. Dabei sind numerische Filtervorgänge am schnellsten, alphanumerische langsamer. Am langsamsten ist der LIKE (WIE) -Operator , weil der massive Zeichen(Text)verarbeitung benötigt und nicht auf Indizierungen zurückgreifen kann.
Das Filtern ist ja auch nur das Überprüfen jedes einzelnen
Datensatzes ob er den geforderten Kriterien entspricht, damit
dieser in die temporäre Abfragetabelle geschrieben werden
darf. Ist diese Tabelle dannoch mit einer Anderen verknüpft
erfolgt auf diese ebenfalls ein Filter um den Zugehörigen
Datensatz zufinden.
Das solltest Du die Sorge der Jet-Engine ( Accesss-DB-System) sein lassen. Die SQL (Abfragen) werden intern passend optimiert.
Das geht natürlich wahnsinnig schnell mit den heutigen
Rechnern. Aber es ist schon ein unterschied ob 1.000 oder
50.000. Ok es sind nur Millisekunden wenn der Prozessor gerade
nichts anderes zutun hat. Aber trotzdem *schmoll*
Das gleiche gilt übrigens auch in der Programmierung, bei der
heutigen Technik ist es vielen Programmierern egal ob 50.000
Zeilen Quellcode oder 1.000 Zeilen für das gleiche Ergebniss
brauchen. Haben doch genug Prozesorleistung und RAM zur
Verfügung. Diese Diskussusion schweift jetzt aber vom Thema ab
also schluß damit
ok, das ist hier wirklich nicht das Thema.
Sollte ich das falsch sehen, lasse ich mich gerne belehren.
„belehren“ will Dich keiner… , nur besser aufklären.
Stell Dir einfach die Sachlage so vor:
Wenn ein Formular in seiner Datenherkunft eine Abfrage oder Tabelle enthält (oder auch dynamisch per Code zugewiesen bekommt), wird beim Öffnen (Laden) des Formulares ein Formular-Recordset erstellt, der die durch die Abfrage gefilterten Datensätze enthält. Dieser Recordset wird durch den User während der Formularbedienung bearbeitet. Sobald nun ein Datensatzwechsel oder das Schliessen des Forms stattfindet, wird der akt. Recordset-Datensatz in die Tabelle geschrieben, sofern man das selber nicht anderweitig unterbunden hat.
Zu diesem Zeitpunkt ist ein Form auf einem anderen PC (User) , das den selben Datensatz anzeigt, noch nicht aktualisiert, das passiert erst nach Ablauf des o. g. Aktualisierungsintervalls. Es kann Situationen geben, bei denen der Datensatz (oder Teile davon) anderweitig angezeigt wird, z. B. in einem Listenfeld oder Kombifeld. Dann ist ein explizites Requery dieses Feldes nötig.
Ein Requery (Refresh tut es auch…) für das Formular auf dem anderen PC kann man natürlich trotzdem durchführen, wenn man es tun möchte. Dabei sollte aber auch das für die spezielle Situation geeignete Ereignis gewählt werden.
Ein Filter auf den Formular-Recordset ist in der Tat langsamer als ein Filter (Kriterium) auf eine Abfrage. Aber da spielt die o. g. Rechner-Schnelligkeit stärker mit hinein.
Alles in Allem passiert im Hintergrund wesentlich mehr an „Datenverarbeitung“ als man als User am Monitor überhaupt erkennen kann.
Viele Grüße vom Bodensee
Franz , DF6GL
PS: Feedback erwünscht!
