10
Umstellung von ADO MDB auf DAO ODBC
Hallo zusammen,
nach jahrelanger Verdrängung habe ich mich nun entschieden dieses Jahr das ganze über die Bühne zu bringen.
Wir arbeiten hier mit einer Access2000 Anwendung (mehrere MDB Frontends die auf verschiedene MDB Backends zugreifen, ca. 40 Nutzer).
Das ganze noch mit ADO.
Die MDB frontends würde ich gerne lassen, weil schneller eine Oberfläche mit Formularen/Reporten basteln wird wohl kaum gehen, es ei denn ihr belehrt mich eines bessern ;).
Ich habe mir ein erstes frontend rausgepickt (ca. 10 Nutzer arbeiten damit auf 3 verschiedenen Tabellen).
Habe von ADO auf DAO umgestellt, die 2 Tabellen in einen SQL 2008 R2 Server gelegt (die 3. Tabelle verbleibt noch in dem mdb-backend (da greifen noch andere drauf zu)),
via ODBC ins frontend eingebunden und auf die Nutzer losgelassen und -> es ist merklich langsamer geworden
Kann es damit zu tun haben das das frontend jetzt gemischt arbeiten muss, also noch mit einer Tabelle aus dem mdb backend und zwei über odbc ?
(das es also vorher schneller war weil noch alles "mdb" war oder noch alles ADO ?)
Würde es was bringen das frontend von mdb auf accdb umzustellen ?
(meine Annahme: das in der neueren Access Variante noch was am Zugriffsmodell optimiert wurde)
Am frontend optimieren: wüsste ich jetzt gar nicht groß wo.
Die Tabellen selber:
Tabelle 1 120 Datenfelder zu ca. 40.000 Datensätzen ( liegt in einer mdb)
Tabelle 2 10 Datenfelder zu ca. 7000 Datensätzen (auf dem SQL Server)
beide über ihren PK miteinander verbunden
Tabelle 3 8 Datenfelder zu ca. 160.000 Datensätzen mit PK Identity und einem
Datenfeld mit einer n:1 Beziehung zum PK aus Tabelle 2 (auch auf dem SQL Server)
Die Performance Einbrüche entstehen im frontend bei den Such(Filter)anfragen bzw. beim Öffnen eines Berichtes.
Dabei werden die Daten Tabelle1<PK---PK>Tabelle2<PK---[Datenfeld]>Tabelle3 angezeigt und gefiltert über den PK in Tab1.
Mit Einbruch reden wir jetzt von 1-2 sec. im Vergleich zu vorher 0,5sec.
MDB in einer Win Freigabe und SQL Server laufen auf dem selben W2008 Server.
Jemand eine Idee oder ist das schlicht und einfach so ?
nach jahrelanger Verdrängung habe ich mich nun entschieden dieses Jahr das ganze über die Bühne zu bringen.
Wir arbeiten hier mit einer Access2000 Anwendung (mehrere MDB Frontends die auf verschiedene MDB Backends zugreifen, ca. 40 Nutzer).
Das ganze noch mit ADO.
Die MDB frontends würde ich gerne lassen, weil schneller eine Oberfläche mit Formularen/Reporten basteln wird wohl kaum gehen, es ei denn ihr belehrt mich eines bessern ;).
Ich habe mir ein erstes frontend rausgepickt (ca. 10 Nutzer arbeiten damit auf 3 verschiedenen Tabellen).
Habe von ADO auf DAO umgestellt, die 2 Tabellen in einen SQL 2008 R2 Server gelegt (die 3. Tabelle verbleibt noch in dem mdb-backend (da greifen noch andere drauf zu)),
via ODBC ins frontend eingebunden und auf die Nutzer losgelassen und -> es ist merklich langsamer geworden
Kann es damit zu tun haben das das frontend jetzt gemischt arbeiten muss, also noch mit einer Tabelle aus dem mdb backend und zwei über odbc ?
(das es also vorher schneller war weil noch alles "mdb" war oder noch alles ADO ?)
Würde es was bringen das frontend von mdb auf accdb umzustellen ?
(meine Annahme: das in der neueren Access Variante noch was am Zugriffsmodell optimiert wurde)
Am frontend optimieren: wüsste ich jetzt gar nicht groß wo.
Die Tabellen selber:
Tabelle 1 120 Datenfelder zu ca. 40.000 Datensätzen ( liegt in einer mdb)
Tabelle 2 10 Datenfelder zu ca. 7000 Datensätzen (auf dem SQL Server)
beide über ihren PK miteinander verbunden
Tabelle 3 8 Datenfelder zu ca. 160.000 Datensätzen mit PK Identity und einem
Datenfeld mit einer n:1 Beziehung zum PK aus Tabelle 2 (auch auf dem SQL Server)
Die Performance Einbrüche entstehen im frontend bei den Such(Filter)anfragen bzw. beim Öffnen eines Berichtes.
Dabei werden die Daten Tabelle1<PK---PK>Tabelle2<PK---[Datenfeld]>Tabelle3 angezeigt und gefiltert über den PK in Tab1.
Mit Einbruch reden wir jetzt von 1-2 sec. im Vergleich zu vorher 0,5sec.
MDB in einer Win Freigabe und SQL Server laufen auf dem selben W2008 Server.
Jemand eine Idee oder ist das schlicht und einfach so ?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 311846
Url: https://administrator.de/contentid/311846
Ausgedruckt am: 05.11.2024 um 12:11 Uhr
10 Kommentare
Neuester Kommentar
Moin,
sorry ohne alle Details verinnerlicht zu haben, aber ist ADO MDB nicht die Technik von gestern und DAO und ODBC die von vorgestern? Warum stellst du nicht auf die von heute um?
Henning
sorry ohne alle Details verinnerlicht zu haben, aber ist ADO MDB nicht die Technik von gestern und DAO und ODBC die von vorgestern? Warum stellst du nicht auf die von heute um?
Habe von ADO auf DAO umgestellt, die 2 Tabellen in einen SQL 2008 R2 Server gelegt (die 3. Tabelle > verbleibt noch in dem mdb-backend (da greifen noch andere drauf zu)),
Dieser Mischbetrieb macht es sicherlich langsamer.Henning
ADO MDB von gestern, da gehe ich mit dir, warum ist DAO mit ODBC von vorgestern ? Habe ich was verpasst ? Ich zitiere mal MS vom Juli 2016:
"Wenn Sie die Geschwindigkeit des Microsoft Jet-Datenbankmoduls mit der zusätzlichen Funktionalität von DAO-Klassen kombinieren möchten, sollte der Zugriff auf ODBC-Datenquellen über die DAO-Klassen erfolgen."
"Wenn Sie die Geschwindigkeit des Microsoft Jet-Datenbankmoduls mit der zusätzlichen Funktionalität von DAO-Klassen kombinieren möchten, sollte der Zugriff auf ODBC-Datenquellen über die DAO-Klassen erfolgen."
ADO is much more recent, DAO is old school.
http://www.c-sharpcorner.com/article/from-dao-to-ado-net/
Regards
http://www.c-sharpcorner.com/article/from-dao-to-ado-net/
Regards
Wahrscheinlich hab ich eher etwas verpasst. Ich dachte, dass DAO der Vorgägnger von ADO ist. Nun findet man aber viele Pro und Kontras im Netz und von DAO 2 (inoffiziel) habe ich auch gelesen. Aber wie schon gesagt, dein Mischbetrieb ist für die Performance sicher nicht gut.
lass mal mir ging es nicht anders, ich hab um 2002 rum von DAO auf ADO umgestellt, weil es MS ohne Ende gehypt hat (übrigens der link von highload ist von 2003 
und habe auch kürzlich immer wieder pro und contras gelesen, naja und dann war ich halt auf das von MS gestossen und ...
Zitat: " ... Empfehlung von Microsoft, mit der auch DAO vor ADO propagiert wird, sondern insbesondere in der Abkündigung des Providers Microsoft OLE DB Provider for SQL Server. Genau diesen verwendet ADO für den Zugriff auf SQL Server. Laut Angaben von Microsoft wird dieser Provider mit dem Ende des Supports von SQL Server 2012 im Sommer 2017 nicht mehr ... " usq usw
Zitat aus "Access und SQL Server" Minhorst,Jungbluth 2013
und deshalb mein Schritt zu DAO
ich nehm mal den Mischbetrieb raus, hole die 3.Tab in den Server und kuck was passiert
und habe auch kürzlich immer wieder pro und contras gelesen, naja und dann war ich halt auf das von MS gestossen und ...Zitat: " ... Empfehlung von Microsoft, mit der auch DAO vor ADO propagiert wird, sondern insbesondere in der Abkündigung des Providers Microsoft OLE DB Provider for SQL Server. Genau diesen verwendet ADO für den Zugriff auf SQL Server. Laut Angaben von Microsoft wird dieser Provider mit dem Ende des Supports von SQL Server 2012 im Sommer 2017 nicht mehr ... " usq usw
Zitat aus "Access und SQL Server" Minhorst,Jungbluth 2013
und deshalb mein Schritt zu DAO
ich nehm mal den Mischbetrieb raus, hole die 3.Tab in den Server und kuck was passiert
Hallo @greatmgm,
im Allgemeinen kann man sagen, wenn es um kleine lokale Datenbanken geht ist DAO einen Tick schneller, ADO sollte man eher verwenden wenn die Datenbanken größer werden und auf sie per Remote zugegriffen wird. Dort spielt ADO eher seine Stärke aus.
Aber ich würde besser gleich zu den .NET Klassen greifen. Oder sich mit c# etc. eine COM-Bibliothek schreiben die die .NET Klassen für den Zugriff nutzt wenn man denn Access weiterhin als Frontend betreibt.
Grüße Uwe
im Allgemeinen kann man sagen, wenn es um kleine lokale Datenbanken geht ist DAO einen Tick schneller, ADO sollte man eher verwenden wenn die Datenbanken größer werden und auf sie per Remote zugegriffen wird. Dort spielt ADO eher seine Stärke aus.
Aber ich würde besser gleich zu den .NET Klassen greifen. Oder sich mit c# etc. eine COM-Bibliothek schreiben die die .NET Klassen für den Zugriff nutzt wenn man denn Access weiterhin als Frontend betreibt.
Grüße Uwe
Guten Morgen,
ah perfekt , das ist doch ein Wort. Dann schau ich mir gleich mal die .NET Klassen an ... Hast du zufällig ein Link parad ?
ah perfekt , das ist doch ein Wort. Dann schau ich mir gleich mal die .NET Klassen an ... Hast du zufällig ein Link parad ?
Schaust du hier rein:
System.Data.SqlClient
System.Data.SqlClient
1000Dank.
Keine Ursache.
Schöne Arbeitswoche
Grüße Uwe
Schöne Arbeitswoche
Grüße Uwe
