Hallo zusammen,
wir haben ein Problem, welches erst durch das viele HomeOffice sichtbar geworden ist.
Wir haben eine Datenbank, welche auf einem Netzwerkserver liegt - Darauf wird über ein Frontend (liegt bei jedem User auf dem eigenen Rechner) zugegriffen.
Solange nur ein einziger User auf die Datenbank zugreift, funktioniert auch alles wunderbar. Doch sobald ein User dazu kommt und eine einzige Änderung in einem Datensatz vornimmt, wird die Datenbank extrem langsam und jeder Filter dauert etwa 2-3min.
Die Datenbankstruktur kann leider auf die schnelle nicht geändert werden (Leider ist diese total falsch aufgebaut): Eine große Tabelle mit sehr vielen Spalten.
Hat irgendjemand von euch einen Vorschlag, wie man die Datenbank etwas beschleunigen kann? Leider benötigt man immer vorab alle Daten und Filtert sich diese zurecht.... Es ist quasi eine Auswahlabfrage der gesamten Tabelle.
Habe schon so viel gelesen und getestet, doch leider hat nichts geholfen.
Permanente Verbindung usw. wurde ausprobiert, hat nichts geholfen.
Ich lese oft von OBDC Datenbanken, aber dafür benötigt man wohl extra Services, welche man erst ordern müsste.
Würde mich über Tipps sehr freuen.
Viele Grüße,
leparain
Hallo,
da wird wohl die magere DSL-(Internet-)Verbindung ihre Wikung zeigen.
Da hilft nur, auf dem Netzwerk-Server für jeden User einen (Terminal-Server-) Account einzurichten und dort in seinem Bereich Access (Office oder Runtime) und das FE zu installieren. Der Zugriff von den lokalen Home-Office-PCs erfolgt dann über DesktopRemoteVerbindung (RDP) .
Statt TS könnten auch VMs oder Hardware-Pcs in Frage kommen.
Alternativen sind aktive SQL-Server (MSSQL, MySQL, etc.) und angepasstes DB-Design.
Vielen Dank für die Antwort.
Ja, es liegt an der DSL Leitung. Die meisten von uns nutzen eine 50k DSL Leitung.
Und bei einem MySQL Server würde er nicht jedes mal alle Daten neu laden, sondern nur diejenigen aktualisieren, welche verändert worden sind oder?
Gibt es auch eine Step by Step Anleitung für eine MySQL Datenbank (Hier im Forum?)? Welche Lizenzen benötigt werden usw?
Ich hab dazu schon so viel gelesen, aber es hört sich so an, als ob da ziemlich viel programmierarbeit dahinter steckt.
Hallo,
sind die Felder in/mit denen gefiltert wird indiziert ?
Zitat von: leparain am Januar 13, 2022, 16:11:25Und bei einem MySQL Server würde er nicht jedes mal alle Daten neu laden, sondern nur diejenigen aktualisieren, welche verändert worden sind oder?
Eine interessante Frage.
Es gibt ja einen dynamic Cursor.
DAO lesen ich - nur bei ODBCDirect - das gibts aber nicht mehr. Ja ja der Fortschritt bei DAO.
Hat das irgend wer schon mal früher verwendet - oder noch im Einsatz.
Ansonsten grundsätzlich - Änderungen anderer User zeigt Access standardmäßig auch an.
Da die Daten bei einem Key-Cursor beim Scrollen automatisch ständig neu ausgelesen werden.
Nur neue Datensätze oder Löschungen werden nicht angezeigt.
Aber bei jedem Filtern müssen alle Daten neu ausgelesen werden.
Da ändert auch ein SQL-Server nichts - das Filtern geht aber trotzdem schneller - so lange das der Server macht.
Einzige Lösung ein Client Cursor - wo für das Filtern keine Datenbank erforderlich ist.
Aber da braucht man dann eine eigene Strategie um Änderungen anderer User anzuzeigen.
Da wird's es recht schwierig.
Zitat von: MzKlMu am Januar 13, 2022, 17:08:29Hallo,
sind die Felder in/mit denen gefiltert wird indiziert ?
Ja, die Spalten an denen meistens gefiltert wird, sind indiziert.
Dennoch dauert es dann z.B. ewig wenn man auf "Filter entfernen" drückt, da er dann komplett neu lädt (sind etwa 150MB die er dann jedesmal neu laden muss).
Und irgendwie ist die Geschwindigkeit auf 1,5mb/s begrenzt, obwohl die Leitung mehr könnte (Liegt das ggf. am VPN Client?).
Zitat von: markus888 am Januar 13, 2022, 17:52:20Zitat von: leparain am Januar 13, 2022, 16:11:25Und bei einem MySQL Server würde er nicht jedes mal alle Daten neu laden, sondern nur diejenigen aktualisieren, welche verändert worden sind oder?
Eine interessante Frage.
Es gibt ja einen dynamic Cursor.
DAO lesen ich - nur bei ODBCDirect - das gibts aber nicht mehr. Ja ja der Fortschritt bei DAO.
Hat das irgend wer schon mal früher verwendet - oder noch im Einsatz.
Ansonsten grundsätzlich - Änderungen anderer User zeigt Access standardmäßig auch an.
Da die Daten bei einem Key-Cursor beim Scrollen automatisch ständig neu ausgelesen werden.
Nur neue Datensätze oder Löschungen werden nicht angezeigt.
Aber bei jedem Filtern müssen alle Daten neu ausgelesen werden.
Da ändert auch ein SQL-Server nichts - das Filtern geht aber trotzdem schneller - so lange das der Server macht.
Einzige Lösung ein Client Cursor - wo für das Filtern keine Datenbank erforderlich ist.
Aber da braucht man dann eine eigene Strategie um Änderungen anderer User anzuzeigen.
Da wird's es recht schwierig.
Wenn es bei einem SQL Server so wäre, dass er die ganzen Daten einmalig laden würde und daraufhin das Filtern usw sehr schnell wäre und daraufhin nicht jedesmal neu laden müsste, wäre es optimal - Gibt es da Erfahrungen?
Vielen Dank für die Antworten !
Zitat von: leparain am Januar 14, 2022, 18:30:54Wenn es bei einem SQL Server so wäre, dass er die ganzen Daten einmalig laden würde und daraufhin das Filtern usw sehr schnell wäre und daraufhin nicht jedesmal neu laden müsste, wäre es optimal - Gibt es da Erfahrungen?
Vom Prinzip her gibt es zwei Möglichkeiten.
Du hast einen Server.
Die Abfrage muss so übermittelt werden, dass die Abfrage vom Server ausgeführt wird.
Dann kommen nur noch die gefilterten Daten übers Netz - müssen aber trotzdem jedes mal neu geladen werden.
Bei der zweiten Möglichkeit werden einfach alle Daten über einen Client Cursor geladen - also nicht nur die Schlüssel, sondern tatsächlich alles.
Da ist es egal ob Server oder Access Datenbank.
Sobald alle Daten einmal abgerufen wurden, werden sie nur noch vom Frontend gefiltert und sortiert.
Auch neue Datensätze werden sortiert eingefügt ohne Daten neu zu laden.
Da nimmt man einfach ein ADO Recordset.
Du erfährst aber nicht, wenn irgend wer zwischenzeitlich die Daten ändert.
Bei modernen Softwareumgebungen, kann der Server das dem Client direkt mitteilen und ausschließlich die Änderungen werden geladen.
Da ist Access im Nachteil und man muss sich überlegen wie man damit umgeht, damit Access nur die Änderungen laden muss.
Filtern dauert aber nur noch Millisekunden, auch ohne Index.
Zitat von: markus888 am Januar 14, 2022, 19:09:45Zitat von: leparain am Januar 14, 2022, 18:30:54Wenn es bei einem SQL Server so wäre, dass er die ganzen Daten einmalig laden würde und daraufhin das Filtern usw sehr schnell wäre und daraufhin nicht jedesmal neu laden müsste, wäre es optimal - Gibt es da Erfahrungen?
Vom Prinzip her gibt es zwei Möglichkeiten.
Du hast einen Server.
Die Abfrage muss so übermittelt werden, dass die Abfrage vom Server ausgeführt wird.
Dann kommen nur noch die gefilterten Daten übers Netz - müssen aber trotzdem jedes mal neu geladen werden.
Bei der zweiten Möglichkeit werden einfach alle Daten über einen Client Cursor geladen - also nicht nur die Schlüssel, sondern tatsächlich alles.
Da ist es egal ob Server oder Access Datenbank.
Sobald alle Daten einmal abgerufen wurden, werden sie nur noch vom Frontend gefiltert und sortiert.
Auch neue Datensätze werden sortiert eingefügt ohne Daten neu zu laden.
Da nimmt man einfach ein ADO Recordset.
Du erfährst aber nicht, wenn irgend wer zwischenzeitlich die Daten ändert.
Bei modernen Softwareumgebungen, kann der Server das dem Client direkt mitteilen und ausschließlich die Änderungen werden geladen.
Da ist Access im Nachteil und man muss sich überlegen wie man damit umgeht, damit Access nur die Änderungen laden muss.
Filtern dauert aber nur noch Millisekunden, auch ohne Index.
Vielen Dank für die Antwort.
Werde aus den "ADO Recordsets" einfach nicht schlau.
Mal angenommen ich habe eine Tabelle "Beispiel" und eine Abfrage "qryBeispiel" die alle Felder von der Tabelle "Beispiel" zurück gibt.
Mehr brauche ich auch nicht. Wie kann ich nun die Abfrage als ADO Recordset öffnen? Finde bei Google leider keinen konkreten Fall.
Vielen Dank und Gruß,
Adam
Zitat von: leparain am Januar 19, 2022, 11:00:52Wie kann ich nun die Abfrage als ADO Recordset öffnen? Finde bei Google leider keinen konkreten Fall.
Ernsthaft? -> https://www.google.com/search?q=ADO+open+recordset
Unter den ersten Ergebnissen finde sich z.B.: Open ADO connection and Recordset objects (https://docs.microsoft.com/en-us/troubleshoot/sql/connect/open-ado-connection-recordset-objects) - Das zeig verschiedene Ansätze. Nur den Connection-String musst du sicherlich anpassen.
Zitat von: markus888 am Januar 13, 2022, 17:52:20DAO lesen ich - nur bei ODBCDirect - das gibts aber nicht mehr. Ja ja der Fortschritt bei DAO.
Hat das irgend wer schon mal früher verwendet - oder noch im Einsatz.
Früher verwendet: Ja. Noch im Einsatz: Nein.
Zitat von: PhilS am Januar 19, 2022, 11:40:51Zitat von: leparain am Januar 19, 2022, 11:00:52Wie kann ich nun die Abfrage als ADO Recordset öffnen? Finde bei Google leider keinen konkreten Fall.
Ernsthaft? -> https://www.google.com/search?q=ADO+open+recordset
Unter den ersten Ergebnissen finde sich z.B.: Open ADO connection and Recordset objects (https://docs.microsoft.com/en-us/troubleshoot/sql/connect/open-ado-connection-recordset-objects) - Das zeig verschiedene Ansätze. Nur den Connection-String musst du sicherlich anpassen.
Danke für die Antwort - Das hatte ich natürlich auch gefunden.
Ich check diese Seite aber einfach nicht... Ich versuche den Code bei mir einzubauen und anzupassen und schon in der aller ersten Zeile kommt ein Fehler "Benutzerfriedenter Typ nicht definiert"....
Müssen spezielle Verweise aktiv sein?
Zitat von: leparain am Januar 19, 2022, 12:20:47Ich check diese Seite aber einfach nicht... Ich versuche den Code bei mir einzubauen und anzupassen und schon in der aller ersten Zeile kommt ein Fehler "Benutzerfriedenter Typ nicht definiert"....
Müssen spezielle Verweise aktiv sein?
Das war mein Einstieg - bereits etwas veraltet: https://activevb.de/tutorials/tut_adokurs/adokurs.html
Da gibts auch jede Menge Schritt für Schritt Anleitungen.
Möglicherweise ist es besser man nimmt sich was Kostenpflichtiges, falls deine eigene Zeit was wert ist.
https://access-basics.de/index.php/ADODB_als_Alternative_zu_DAO.html
Zitat von: leparain am Januar 19, 2022, 12:20:47"Benutzerfriedenter Typ nicht definiert"....
Müssen spezielle Verweise aktiv sein?
Ja, allerdings. - Wenn es vorher bei dir bereits gescheitert ist, hättest du die Fehlermeldung erwähnen sollen.
Du brauchst einen Verweis auf "Microsoft ActiveX Data Objects X.Y Library", wobei X.Y die Versionsnummer ist. MM. ist da jede Version von 2.1 bis 6.1 OK. Solange deine Anwendung nicht auf irgendwelchen Uralt-PCs laufen soll, nimm die neuste die bei dir vorhanden ist.
Zitat von: PhilS am Januar 19, 2022, 11:42:40Zitat 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?
Wäre schön, wenn du dich noch erinnern kannst.
Könnt ihr mir bitte weiterhelfen?
Nachdem ich nun eineige Codes ausprobiert habe, funktioniert es (glaube ich) nicht.
Folgender Code:
Private Sub Befehl2_Click()
Dim db As ADODB.Connection
Dim rs As New ADODB.Recordset
Set db = CurrentProject.Connection
rs.Open "Tabelle", cnThisConnect, adOpenDynamic, _
adLockOptimistic, adCmdTableDirect
End Sub
Die "Tabelle" ist eine verlinkte Tabelle. Die Schaltfläche befindet sich einfach auf einem Formular. Beim draufklicken lädt er kurz was, danach passiert aber nichts mehr... Hatte gedacht es öffnet sich dann eine neue Tabelle oder sonstiges.
Mein Ziel ist es im Moment, dass sich einfach die "Tabelle" als ADO.Recordset öffnet (Denke ich)
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
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?
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)?
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.
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.
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.
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.
Zitat von: markus888 am Januar 19, 2022, 13:06:07Zitat von: PhilS am Januar 19, 2022, 11:42:40Zitat 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 (https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/query-notifications-in-sql-server) verwechselt hast? - Beides hat nichts miteinander zu tun. ODBC-Direct gab es schon ca. 20 Jahre vor den Query Notifications.
Zitat von: PhilS am Januar 22, 2022, 14:33:30Kann es sein, dass du ODBC-Direct mit SQL Server Query Notifications (https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/query-notifications-in-sql-server) 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