Mai 25, 2022, 12:07:40

Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!


Performance Problem - Mehruser (Frontend/Backend)

Begonnen von leparain, Januar 13, 2022, 12:13:33

⏪ vorheriges - nächstes ⏩

DF6GL

Hallo,

was soll da angezeigt werden?

Es wird ein Recordset geöffnet (geladen) und das war es auch schon.

Um die Recordsetdaten anzuzeigen, kannst Du z. B. das Recordset dem Formular-Recordset zuweisen, das entspr. Steuerelemente (textfelder besitzt:

Me.Reordset = rs



leparain

Zitat von: DF6GL am Januar 19, 2022, 15:18:18Hallo,

was soll da angezeigt werden?

Es wird ein Recordset geöffnet (geladen) und das war es auch schon.

Um die Recordsetdaten anzuzeigen, kannst Du z. B. das Recordset dem Formular-Recordset zuweisen, das entspr. Steuerelemente (textfelder besitzt:

Me.Reordset = rs




Danke für die Antwort.

Also kann ich keine ganze Abfrage bzw. Tabelle anzeigen lassen?
Wenn ich mir nur bestimmte Datensätze angezeigt bekomme, welche ich vorher genau definieren muss und in ein Formular übergeben muss, hilft mir das ja nicht weiter.

Oder soll ich ein Formular als "Datenblatt" erstellen? Wie müsste ich dann den Code anpassen, wenn ich ein Formular Namens "Recordset" habe und dort alle Felder von meiner Tablle habe?

Geht das überhaupt so wie ich es mir vorstelle?


markus888

Zitat von: leparain am Januar 19, 2022, 15:23:47Also kann ich keine ganze Abfrage bzw. Tabelle anzeigen lassen?

Geht das überhaupt so wie ich es mir vorstelle?


Bei den Fragen die du hier stellst, hat man nicht das Gefühl, dass du nicht der Richtige für das Thema bist.
Arbeitet ihr bisher ohne selbst erstellte Formulare (Tabellenansichten sind ja auch nur Formulare)?
10 Jahre Access

MzKlMu

Hallo,
ZitatOder soll ich ein Formular als "Datenblatt" erstellen? Wie müsste ich dann den Code anpassen, wenn ich ein Formular Namens "Recordset" habe und dort alle Felder von meiner Tablle habe?
Da braucht es keinen Buchstaben VBA.
Mir scheint, da fehlen wesentliche Grundlagen zu Access.

Warum bindest Du das Formular nicht einfach an die Tabelle`?

Du kannst mal mit dem Formularassi ein Formular erstellen und wählst als Datenquelle die Tabelle.
Dann siehst Du wie das geht.
Gruß
Klaus

leparain

Zitat von: MzKlMu am Januar 19, 2022, 17:48:09Hallo,
ZitatOder soll ich ein Formular als "Datenblatt" erstellen? Wie müsste ich dann den Code anpassen, wenn ich ein Formular Namens "Recordset" habe und dort alle Felder von meiner Tablle habe?
Da braucht es keinen Buchstaben VBA.
Mir scheint, da fehlen wesentliche Grundlagen zu Access.

Warum bindest Du das Formular nicht einfach an die Tabelle`?

Du kannst mal mit dem Formularassi ein Formular erstellen und wählst als Datenquelle die Tabelle.
Dann siehst Du wie das geht.

Das haben wir alles schon (auch von mir erstellt).
Formulare mit Filtermasken über Kombinationsfeldern usw. das funktioniert auch alles richtig gut, solange man in der Firma ist (schnelle Verbindung zum Server).

Hatte ja nach einer Alternativlösung gefragt, da abfragen zum Teil sehr lange dauern (Große Tabelle mit vielen Daten).

Und da war ja dann von ADO Datensätzen die Rede, nur finde ich absolut kein einziges Beispiel, wo das so angewendet wird.
Wenn ich als Datensatzquelle im Formular die Tabelle verwende, wo ist da der Geschwindigkeitsgewinn, wenn ich alle Daten brauche, welche ich auch direkt über eine Tabelle/Abfrage erhalte?

Hatte jetzt gedacht, dass man wohl ein Formular erstellt und die Daten als ADO Recordset darstellt, müsste ich dann wohl aber jedes einzelne Steuerelement mit einem VBA Befehl zuweisen, dass es ein ADO Recordset von der Tabelle mit der jeweiligen Spalte enthält.

Hatte sich halt für mich so angehört am Anfang, dass ich eine Abfrage erhalte (Nach klick oder öffnen eines Formulars), welche eben aus ADO Recordsets besteht.

Aber so drehe ich mich im Kreis und komme leider nicht weiter. Danke in jedem Fall für eure Hilfe / Links wo das Thema ordentlich erklärt ist, ich mir daraus aber nichts für mich ableiten kann.

DF6GL

Hallo,


die Verwendung eines BE über eine Internet-Leitung ist grundsätzlich nicht zu empfehlen.
Zum einen werden, wenn nicht ein aktiver SQl-Server mit enspr. Programmierung (Views, SP, usw.) im Einsatz ist, massenhaft Daten zunächst lokal kopiert und danach erst ausgewertet, was die Sache entspr. langsam macht. Das gilt auch bei Benutzung von ODBC-Treibern.

Zum anderen birgt eine instabile IN-Verbindung die Gefahr zu korrumpierten BEs in sich.


Vom Datenschutz ganz zu schweigen, wenn nicht eine sichere VPN-Verbindung eingerichtet ist.


Besser in jedem Fall wäre ein Terminal-Server-Betrieb mit separaten Accounts für jeden User oder Remote-Desktop-Zugriff auf user-dedizierte Virtuelle Maschinen oder auch Hardware-PCs.


Und hier auch nur via VPN-Tunnel.










markus888

Zitat von: DF6GL am Januar 19, 2022, 21:18:41wenn nicht ein aktiver SQl-Server mit enspr. Programmierung (Views, SP, usw.) im Einsatz ist, massenhaft Daten zunächst lokal kopiert und danach erst ausgewertet, was die Sache entspr. langsam macht. Das gilt auch bei Benutzung von ODBC-Treibern.


Das kann man nicht oft genug betonen.
Access zur Datenhaltung sollte im Netzwerkbetrieb generell nicht eingesetzt werden.
Gegen Stand-Alone Anwendungen gibt es da weit weniger einzuwenden.

Einfach mal einen Server im Betrieb nehmen und die Unterschiede testen.
Möglicherweise ist das ja bereits ausreichend für euere Situation.
Das sollte aber jemand machen, der weiß was er tut. Das beginnt schon beim Aufbau und dem Abrufen der Daten.
Wenn der nicht passt, dann ist Ineffizienz vorprogrammiert.
10 Jahre Access

PhilS

Zitat von: markus888 am Januar 19, 2022, 13:06:07
Zitat von: PhilS am Januar 19, 2022, 11:42:40
Zitat von: markus888 am Januar 13, 2022, 17:52:20DAO lesen ich - nur bei ODBCDirect
DAO.Früher verwendet: Ja. Noch im Einsatz: Nein.

Darf ich nach deiner Erfahrung fragen?
Ich stelle mir vor, dass der Mehr-Aufwand für den Server und den Datenprovider nicht ohne ist.

Werden neue Datensätze in sortierter Reihenfolge geliefert und werden die Änderungen vom Formular automatisch angezeigt?
Auswertebare Events gibts meines Wissens ja keine, damit man irgendwie reagieren könnte.
Kommen die Änderungen unmittelbar?
Ich glaube, ich verstehe deine Fragen nicht.

Das wesentliche Merkmal von ODBC-Direct mit DAO ist, dass die JET/ACE-Engine komplett umgangen wird. Also praktisch dasselbe wie Pass-Through-Abfragen, nur dass es keinen DAO.Database-Container für diese Abfragen geben muss. Somit ist das ganze recht ähnlich zu ADO, aber beschränkt auf ODBC anstelle von OLEDB.

Mehraufwand für Server und Datenprovider gibt es keinen. Du gibst einen ConnectionString an, wie für Pass-Through oder ADO auch.

Neue Datensätze bekommst du, wenn du eine Abfrage erneut ausführst, wie für Pass-Through oder ADO auch.


Vorteile von ODBC-Direct gegenüber Pass-Through-Abfragen: Die Parameterübergabe an Stored Procedures kann über die Parameters-Collection erfolgen und unterstützt auch Ouput-Parameter und Return-Values. D.h. Basteleien, wie das zusammensetzen des SQL-Strings mit den Parameter-Werten, entfallen.

Vorteile von ODBC-Direct gegenüber ADO: Absolut keine!

Kann es sein, dass du ODBC-Direct mit SQL Server Query Notifications verwechselt hast? - Beides hat nichts miteinander zu tun. ODBC-Direct gab es schon ca. 20 Jahre vor den Query Notifications.
Neue Videoserie: Windows API in VBA

Klassische CommandBars visuell bearbeiten: Access DevTools CommandBar Editor

markus888

Zitat von: PhilS am Januar 22, 2022, 14:33:30Kann es sein, dass du ODBC-Direct mit SQL Server Query Notifications verwechselt hast? - Beides hat nichts miteinander zu tun. ODBC-Direct gab es schon ca. 20 Jahre vor den Query Notifications.

Na ja, es geht mir ja in erster Linie um den RecordsetType dbOpenDynamic.
Damit sollen ja auch neue Datensätze und Löschungen anderer User, die irgendein geladenes Recordset betreffen angezeigt werden.
Nach meinem Verständnis müsste also der Client per Event über Änderungen in der Zusammensetzung des "Key-Sets" informiert werden und dieser müsste das neue Key-Set vom Server anfordern.

Ist aber eh obsolet, da ODBC-Direct aktuell nicht mehr unterstützt wird.

Mit einem ADO Recordset mit Server Cursor kann ein Access-Formular ja nichts anfangen.
Werde es aber mit einem Datagrid testen, das mit einem ADO Server Cursor umgehen kann.
Dann kann ich mich ja etwas spielen und auch sehen ob Recordset Events ausgelöst werden.

LG Markus

10 Jahre Access