Hallo MSC
Wenn ich das richtig lese, hast Du eine VB6 Anwendung, welche eine MDB als Backend benutzt. Mit Access hat das grundsätzlich nichts zu tun. Auch Access verwendet Jet, um auf die MDB zuzugreifen und Daten
zu verarbeiten und versorgt sogar seine Objekte via Jet in der MDB (oder MDE, was nichts anderes als eine MDB ohne Sourcecode ist).
Du könntest allenfalls versuchen, die MDB in eine neuere Jet Version zu migrieren, ich denke aber, das wird nicht viel bringen, Jet wurde nicht schneller in neueren Versionen. A2000 kam bereits mit der schnellen
JET Engine daher, welche dann später auch über die Betriebssysteme verteilt wurde.
ADO wurde seinerzeit als die alleine glücklich machende neue Zugriffstechnologie angepriesen. Das hat sich dann als Irrweg herausgestellt und nun wird wieder DAO von Microsoft als zu bevorzugende Technologie
angepriesen. DAO war in der Regel immer einen Deut schneller als ADO. Hier könntest Du also evt. was rausholen, hängt halt davon ab, wie tief ADO benutzt wurde und ob alles auch unter DAO 1:1 umsetzbar ist (was nicht immer der Fall ist). Ein Mischbetrieb ist
durchaus auch möglich.
Grundsätzlich lassen sich Performance Probleme von komplexen Anwendungen mit grossen Datenbanken in der Regel einfacher lösen, wenn eine Migration auf einen SQL Server gemacht wird. Wenn Ihr die Anwendung sowieso
im Terminal Server betreibt, dann sollte der Server Betrieb eigentlich kein Problem darstellen. Im SQL Server sind dann wesentlich bessere Antwortzeiten zu erreichen, da es sich hier um einen aktiven Datenbank Manger handelt. Bei JET muss jeweils eine DLL
geladen werden, die die Aufgaben des DAtenbank Managers übernimmt. Dass da das Caching im Mehrbenutzerbetrieb nicht optimal ist, speziell wenn mehrere Benutzer als Terminal Server Anwendung auf der gleichen Hardware rumhämmern, ist eigentlich klar. JET muss
ja für jeden Benutzer geladen und für jeden Benutzer demzufolge einen eigenen Cache aufbauen, der dann die Anwendung in die Knie zwingt. Der SQL Server kann einen grossen Cache für alle Benutzer gleichsam aufbauen, das heisst, wenn ein Benutzer Daten liest,
die zuvor ein anderer Benutzer gelesen hat, dann sind diese bereits im Cache. In Jet müssen diese für jeden Benutzer einzlen aus den Datenbank Pages herausgepflückt und als REcordset zur Verfügung gestellt werden.
Der Wechsel auf .NET wird wohl nicht viel bringen. Die Zugriffsmethoden sind ja dann die gleichen, wenn der Datenbank Manager nicht gewechselt wird. Im Gegenteil: Ich vermute, es wird noch langsamer, weil das
.NET Framework dann wohl auch wieder für jeden Benutzer geladen und gecached werden muss.
Ich würde also folgendes vorschlagen:
- DB Migration zum SQL Server (eine Express Edition tut's auch, wenn bisher eine MDB hergehalten hat)
- evt. Migration zu DAO
Gruss
Henry
Hallo,
ich bin Entwickler einer mittlerweile doch ziemlich komplexen VB6-Anwendung.
Die Datenbasis bilden einige Access Datenbanken in der Version 2000.
Das gro�?e Problem der Anwendung ist die Performance.
Je länger die Anwendung läuft, desto langsamer wird das Porgramm.
Das Programm läuft in der Regel auf Terminalserver.
Bringt es vielleicht etwas, die Datenbanken in eine höhere Access Version zu konvertieren?
Vielleicht Access 2007? Wir greifen über ADO auf die Datenbanken zu, ist DAO evtl schneller?
Am liebsten würde ich die Anwendung natürlich nach .NET migireren, dies ist allerdings auch nicht ganz einfach.
Oft passiert es, das die Anwendung (oder die Datenbank) sich Timeouts gönnt und der BIldschirm für ca. 30 sek einfriert.
Ein Kopiervorgang, welcher nach Installation vll 3-4 sek dauert, dauert nach einem halben Jahr bestimmt 10 mal so lang.
Man hat auch das Gefühl, das die Anwendung die Hardware-Ressourcen gar nicht ausnutzt.
Wenig Erfahrung habe ich im Bereich caching, über Infos hierüber wäre ich sehr dankbar.
Ha jemand Erfahrungen diesbezüglich?Jeder Tip oder jede Anregung ist wirklich sehr willkommen.
- Access 2000 vs Access 2007,
- ADO vs DAO,
- Migration VB6 nach VB.NET
- caching
VB6 mit Access- Performanceprobleme
