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 ?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 311846
Url: https://administrator.de/forum/umstellung-von-ado-mdb-auf-dao-odbc-311846.html
Ausgedruckt am: 23.12.2024 um 08:12 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 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
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
Schaust du hier rein:
System.Data.SqlClient
System.Data.SqlClient