Performance-Problem Access-Backend

Question

Hallo zusammen,

nach einer Infrastrukturumstellung habe ein großes Problem mit einer Access-Anwendung.

Die Anwendung besteht aus Access-Frontend und -Backend und einer C#-Anwendung, die Berechnungen auf dem Backend ausführt.

In der alten Umgebung (Win7/Office2010) lief alles nicht schnell, aber ok. Nachdem das Unternehmen auf Win10 / Office2016 umgestellt hat, dauert das Öffnen und Schließen des Backends über C# anscheinend ca. 20 Sekunden.

Habe das Backend dann testweise auf SQL-Server (2016) umgestellt. Jetzt ist der C#-Zugriff schnell, aber z.B. das Anzeigen einer Liste im Access-Frontend sehr langsam :-(.

Also in der einen Variante ist Access langsam:

Access-Frontend (ODBC-Verbindung mit Native Client) -  SQL-Server-Backend

C#-Berechnung (SQL-Connection)

und in der anderen C#:

Access-Frontend (verknüpfte Tabellen) - Access-Backend

C#-Berechnung (OleDB-Connection)

Leider ist weder die eine, noch die andere Variante so akzeptabel.

Ich weiß nicht, ob das die richtige Community ist. Aber vielleicht hat hier jemand dafür eine Erklärung/Idee?

Bin dankbar für jeden Hinweis - und die Geduld, den ganzen Text zu lesen!

Viele Grüße!

Marion

Answer 1

Am 03.10.2019 schrieb Marion04:

Die Anwendung besteht aus Access-Frontend und -Backend und einer C#-Anwendung, die Berechnungen auf dem Backend ausführt.

In der alten Umgebung (Win7/Office2010) lief alles nicht schnell, aber ok. Nachdem das Unternehmen auf Win10 / Office2016 umgestellt hat, dauert das Öffnen und Schließen des Backends über C# anscheinend ca. 20 Sekunden.

Wo liegt das Backend? Wie sind die Tabellen verknüpft? Per
Laufwerksbuchstabe oder UNC-Pfad?

Habe das Backend dann testweise auf SQL-Server (2016) umgestellt. Jetzt ist der C#-Zugriff schnell, aber z.B. das Anzeigen einer Liste im Access-Frontend sehr langsam :-(.

Wie lange dauert die Abfrage auf dem SQL Server? Oder öffnest Du eine
komplette Tabelle in dem Formular?

Wenn man ein Access-Backend auf den SQL Server auslagert, muss man
sich mit dem SQL Server und seinen Techniken auseinandersetzen. Eins
zu eins übernehmen geht IMO gar nicht.

Wenn Access-Frontend und SQL Backend empfehle ich auf
Tabellenverknüpfungen zu verzichten und nur mit Views oder Stored
Procedures zu arbeiten.

Bernd Jungbluth hat das auf der AEK17 gezeigt. Hier ein paar Beispiele
in einem ZIPFile:
http://www.donkarl.com/Downloads/AEK/AEK17_LogikSQLServer.zip

Servus
Winfried

---

WSUS Package Publisher:
https://github.com/DCourtel/Wsus_Package_Publisher
HowTos zum WSUS Package Publisher
https://www.wsus.de/wsus-package-publisher/
GPO's: http://www.gruppenrichtlinien.de
NNTP-Bridge für MS-Foren:
https://github.com/JochenKalmbach/communitybridge
GP-PACK - PRIVACY AND TELEMETRIE: http://www.gp-pack.com/

Answer 2

Hallo Winfried,

erst Mal vielen Dank für die Erläuterungen und den Link. Natürlich hast Du recht. Eine "richtige" Migration auf SQL-Server Prozeduren, etc. wäre besser. Leider ist das mit zu viel Aufwand verbunden und daher nicht genehmigt.

Ist zwar eine SQL-Server-View, aus der aber eine Abfrage (mit einer Access-Funktion) erstellt wird. Und die wird dann als Liste im Formular angezeigt.  Access/Access ist da anscheinend viel schneller.

Werde es einmal mit einem anderen ODBC-Treiber versuchen.

Viele Grüße

Marion

Answer 3

Am 04.10.2019 schrieb Marion04:

Ist zwar eine SQL-Server-View, aus der aber eine Abfrage (mit einer Access-Funktion) erstellt wird. Und die wird dann als Liste im Formular angezeigt.  Access/Access ist da anscheinend viel schneller.

Du hast im SQL Server eine View erstellt, die bindest Du im FE ein und
erstellst dir daraus wieder eine neue Abfrage? Die Abfrage in Access
kannst Du nicht gleich im SQL Server richtigerweise anlegen?

Die View im SQL Server ist schnell?

Servus
Winfried

---

WSUS Package Publisher:
https://github.com/DCourtel/Wsus_Package_Publisher
HowTos zum WSUS Package Publisher
https://www.wsus.de/wsus-package-publisher/
GPO's: http://www.gruppenrichtlinien.de
NNTP-Bridge für MS-Foren:
https://github.com/JochenKalmbach/communitybridge
GP-PACK - PRIVACY AND TELEMETRIE: http://www.gp-pack.com/

Answer 4

Hallo,

Ist zwar eine SQL-Server-View, aus der aber eine Abfrage (mit einer Access-Funktion) erstellt wird.

Zeig mal die Access-Abfrage mit der Funktion.

Werde es einmal mit einem anderen ODBC-Treiber versuchen. 

Zur Info, der aktuellste Treiber, der auch weiterentwickelt wird, ist: "ODBC Driver 13 for SQL Server"

Gruss - Peter

Answer 5

>> der aktuellste Treiber, der auch weiterentwickelt wird, ist: "ODBC Driver 13 for SQL Server"

Hallo Peter, der neueste ODBC Treiber ist meine Wissens Version 17, Download  siehe https://www.microsoft.com/de-DE/download/details.aspx?id=56567

und Dokumentation https://docs.microsoft.com/en-us/sql/connect/odbc/windows/microsoft-odbc-driver-for-sql-server-on-windows?view=sql-server-2017

Matthias Kläy, Kläy Computing AG

Answer 6

>> der aktuellste Treiber, der auch weiterentwickelt wird, ist: "ODBC Driver 13 for SQL Server"

Hallo Peter, der neueste ODBC Treiber ist meine Wissens Version 17

In der Tat, danke für den Hinweis.

Gruss - Peter

-- 
FAQ: Link
Docs: Link

Answer 7

Hallo zusammen,

Vielen Dank für die Antworten. Ich habe schließlich doch alle Abfragen in Views migriert. Aus der Funktion eine Procedure zu machen, wäre ziemlich aufwändig gewesen. Aber auch mit der Access-Funktion läuft die Abfrage jetzt immer noch schnell :-).

Den neuen Treiber kann ich auch nicht verwenden, da auf den Clients nur der alte SQL-Server-Treiber installiert ist.

Leider handelt es sich um eine Übergangslösung, d.h. es ist  minimaler Aufwand gefragt.

Vielen Dank euch allen und viele Grüße

Marion

Answer 8

Am 09.10.2019 schrieb Marion04:

Vielen Dank für die Antworten. Ich habe schließlich doch alle Abfragen in Views migriert. Aus der Funktion eine Procedure zu machen, wäre ziemlich aufwändig gewesen. Aber auch mit der Access-Funktion läuft die Abfrage jetzt immer noch schnell :-).

OK. ;)

Den neuen Treiber kann ich auch nicht verwenden, da auf den Clients nur der alte SQL-Server-Treiber installiert ist.

Kann man auf den Clients nicht den neuen Treiber installieren? Falls
nein, gibt es einen 'echten' Grund?

Leider handelt es sich um eine Übergangslösung, d.h. es ist  minimaler Aufwand gefragt.

Übergangslösungen haben meistens die Übergangszeit recht schnell
überschritten und fristen dann sehr, sehr lange ihr Dasein. :)

Servus
Winfried

---

WSUS Package Publisher:
https://github.com/DCourtel/Wsus_Package_Publisher
HowTos zum WSUS Package Publisher
https://www.wsus.de/wsus-package-publisher/
GPO's: http://www.gruppenrichtlinien.de
NNTP-Bridge für MS-Foren:
https://github.com/JochenKalmbach/communitybridge
GP-PACK - PRIVACY AND TELEMETRIE: http://www.gp-pack.com/

Answer 9

Ja und nein. Der Verwaltungsaufwand, den neuen Treiber installieren zu lassen, wäre viel höher gewesen, als die Anwendung auf den alten Treiber anzupassen. Und hätte wahrscheinlich Wochen gedauert ;-) 

Und richtig: Nichts ist so langlebig, wie Übergangslösungen :-)

Viele Grüße!

Marion

Answer 10

Am 10.10.2019 schrieb Marion04:

Ja und nein. Der Verwaltungsaufwand, den neuen Treiber installieren zu lassen, wäre viel höher gewesen, als die Anwendung auf den alten Treiber anzupassen. Und hätte wahrscheinlich Wochen gedauert ;-) 

Hust, da ich ja auch Systemadministrator bin, weiß ich wie schnell man
den neuen Treiber (*.MSI) auf die Rechner bringen kann. Wenn ein WSUS
zur Verfügung steht, geht das in 5 Minuten, hat man nur eine Domain
ohne WSUS zur Verfügung, dann dauert es 5 Minuten. Wie lange hat es
gedauert bis die Anwendung angepasst wurde? 1, 2 oder 3 Stunden? :)

Servus
Winfried

---

WSUS Package Publisher:
https://github.com/DCourtel/Wsus_Package_Publisher
HowTos zum WSUS Package Publisher
https://www.wsus.de/wsus-package-publisher/
GPO's: http://www.gruppenrichtlinien.de
NNTP-Bridge für MS-Foren:
https://github.com/JochenKalmbach/communitybridge
GP-PACK - PRIVACY AND TELEMETRIE: http://www.gp-pack.com/

Answer 11

...Mehr als 3 Stunden, mußte noch das Datumsformat von datetime2 auf datetime zurückstellen und danach alle Tabellen neu füllen.

Den Treiber zu installieren geht bestimmt schnell, das Problem (in großen Firmen)  ist der Workflow - Paketbeschreibung, -beauftragung, -erstellung und Installation durch den Dienstleister, Dokumentation, etc. ....Und ohne das Alles darf der Systemadministrator garnichts ;-)

Viele Grüße!

Marion