Benutzer mit den meisten Antworten
VB6 mit Access- Performanceprobleme

Frage
-
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
- Verschoben Robert BreitenhoferModerator Mittwoch, 1. Februar 2012 15:41 Microsoft Access (aus:Visual Basic 6.0 - Interoperabilität und Upgrade)
Antworten
-
Am 31.01.2012 schrieb --MSC--:
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.Was wird dabei langsam? Die VB6 EXE oder der Zugriff auf bestimmte
Tabellen/Views? Wie groß sind die Access Datenbanken? Sind Primary
Keys korrekt gesetzt? Werden die Backends regelmäßig Offline
komprimiert?Bringt es vielleicht etwas, die Datenbanken in eine höhere Access Version zu konvertieren?
Ohne die Ursachen zu können, IMHO nicht.
Vielleicht Access 2007? Wir greifen über ADO auf die Datenbanken zu, ist DAO evtl schneller?
Wenn Du Access als Frontend verwenden würdest, wäre DAO die erste
Wahl. Bei VB6 kannst Du IMHO auch sehr gut mit ADO leben.Am liebsten würde ich die Anwendung natürlich nach .NET migireren, dies ist allerdings auch nicht ganz einfach.
Besser wäre es auf ein richtiges Backend, z.B. den SQL Server zu
wechseln. Die Datenbanken der Express Variante von 2008R2 können 10 GB
groß werden. Eine Access (Jet DB) kann nur 2 GB groß werden.Oft passiert es, das die Anwendung (oder die Datenbank) sich Timeouts gönnt und der BIldschirm für ca. 30 sek einfriert.
Welche Aktionen wurden angestossen?
Ein Kopiervorgang, welcher nach Installation vll 3-4 sek dauert, dauert nach einem halben Jahr bestimmt 10 mal so lang.
Von wo nach wo? Wieviel GB?
Servus
Winfried
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
GPO's: http://www.gruppenrichtlinien.de
Community Forums NNTP Bridge: http://communitybridge.codeplex.com/- Als Antwort vorgeschlagen Robert BreitenhoferModerator Montag, 6. Februar 2012 11:33
- Als Antwort markiert Gunter Avenius Freitag, 23. März 2012 12:45
Alle Antworten
-
Am 31.01.2012 schrieb --MSC--:
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.Was wird dabei langsam? Die VB6 EXE oder der Zugriff auf bestimmte
Tabellen/Views? Wie groß sind die Access Datenbanken? Sind Primary
Keys korrekt gesetzt? Werden die Backends regelmäßig Offline
komprimiert?Bringt es vielleicht etwas, die Datenbanken in eine höhere Access Version zu konvertieren?
Ohne die Ursachen zu können, IMHO nicht.
Vielleicht Access 2007? Wir greifen über ADO auf die Datenbanken zu, ist DAO evtl schneller?
Wenn Du Access als Frontend verwenden würdest, wäre DAO die erste
Wahl. Bei VB6 kannst Du IMHO auch sehr gut mit ADO leben.Am liebsten würde ich die Anwendung natürlich nach .NET migireren, dies ist allerdings auch nicht ganz einfach.
Besser wäre es auf ein richtiges Backend, z.B. den SQL Server zu
wechseln. Die Datenbanken der Express Variante von 2008R2 können 10 GB
groß werden. Eine Access (Jet DB) kann nur 2 GB groß werden.Oft passiert es, das die Anwendung (oder die Datenbank) sich Timeouts gönnt und der BIldschirm für ca. 30 sek einfriert.
Welche Aktionen wurden angestossen?
Ein Kopiervorgang, welcher nach Installation vll 3-4 sek dauert, dauert nach einem halben Jahr bestimmt 10 mal so lang.
Von wo nach wo? Wieviel GB?
Servus
Winfried
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
GPO's: http://www.gruppenrichtlinien.de
Community Forums NNTP Bridge: http://communitybridge.codeplex.com/- Als Antwort vorgeschlagen Robert BreitenhoferModerator Montag, 6. Februar 2012 11:33
- Als Antwort markiert Gunter Avenius Freitag, 23. März 2012 12:45
-
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
Hallo --MSC--,
Zu diesem Thema (Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET) gibt es ein Buch:Free Book - Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET
Grüße,
Robert
Robert Breitenhofer, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
Hallo MSCWenn 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 DAOGrussHenry<--MSC--> wrote in message news:ccab70a2-1808-4d77-910d-3712d0d865e7@communitybridge.codeplex.com...
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
- Als Antwort vorgeschlagen Robert BreitenhoferModerator Montag, 6. Februar 2012 11:33
-
Hallo --MSC--,
Haben Dir die Antworten geholfen?
Grüße,
RobertRobert Breitenhofer, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.