Microsoft Access zeigt sein Alter. Die meisten Techniken (Dateiserver, VBA, DAO, Jet Database Engine usw.) reichen 20 oder mehr Jahre zurück. Microsoft wird VBA noch viele Jahre lang unterstützen, der Schwerpunkt der Programmierung ändert sich jedoch rasch zugunsten von Visual Basic.Net und SQL Server.
Für Unternehmensverwaltungssysteme bietet sich die Kombination eines VB.Net FrontEnds mit einer SQL Server BackEnd Datenbank an. Visual Basic ist auf Geschäftsregeln ausgerichtet und SQL Server ist effizient und einfach zu warten.
GrĂĽnde fĂĽr die Konvertierung des VB.Net-Upgrades
Die GrĂĽnde fĂĽr ein Upgrade von Microsoft Access auf Visual Basic.Net und eine SQL Server-Datenbank sind:
- Eine strategische Unternehmensentscheidung
- Sorgen um die Zukunft von Visual Basic for Applications (VBA)
- Die Schwierigkeit und die Kosten bei der UnterstĂĽtzung veralteten und fehlerbehafteten Codes
- Die Schwierigkeit und die Kosten bei der UnterstĂĽtzung von Code, der von Amateuren ohne RĂĽcksicht auf Standards geschrieben wurde
- Die Notwendigkeit, ein ineffizientes Verwaltungssystem zu ersetzen, das einfach „wie Topsy“ gewachsen ist
- Die Notwendigkeit, umständliche Zugriffsformulare durch eine effizientere Alternative zu ersetzen
- Die Notwendigkeit einer Transaktionsprotokollierung und -wiederherstellung, um die Integrität der Systemdaten sicherzustellen
- Die vielen Eigenheiten von Access-gebundenen Formularen
- Die Leistungsprobleme und das ständige Tuning
- Der hohe Netzwerkverkehr
- Die begrenzte Anzahl gleichzeitiger Benutzer
- Die begrenzte Speicherkapazität für Tabellendatensätze
- Höhere Sicherheitsanforderungen
Aus diesen Gründen kann die Umstellung bestehender Access-Verwaltungssysteme auf VB.Net und eine SQL Server-Datenbank unumgänglich werden.
Die meisten neuen Verwaltungsanwendungen werden heutzutage von professionellen Entwicklern mithilfe eines VB.Net-Frontends und einer SQL Server-Backend-Datenbank entworfen.
Vorgeschlagene Konvertierungsstrategie
Es ist nahezu unmöglich, vorhandenen VBA-Code, Access Forms und Reports in VB.NET zu konvertieren. Es ist viel kostengünstiger, zu versuchen, nur die vorhandene Geschäftsregellogik zu extrahieren und ganz von vorne zu beginnen, neue FrontEnd-Formulare zu erstellen und eine SQL-Datenbank als BackEnd zu verwenden.
In diesem Hinweis werden die Strategien beschrieben, die erforderlich sind, um einige der HĂĽrden, die beim Konvertierungsprozess auftreten, zu minimieren und den Programmieraufwand zu reduzieren.
Identifizieren Sie die Geschäftsregeln
Der Großteil der VBA-Codelogik in Forms wird zur Unterstützung der Benutzeroberfläche verwendet – sie hat in der VB.Net-Umgebung keine Bedeutung. Der Versuch, den formularbezogenen Code zu konvertieren, wird kaum oder gar nichts bringen. Der Konvertierungsaufwand von VBA zu VB.Net sollte sich auf die Identifizierung und Konvertierung der in den VBA-Codemodulen enthaltenen Geschäftsregeln konzentrieren.
Die Entscheidungen zur Konvertierungsstrategie
- Projekt – Es besteht die Möglichkeit, ein MDI-Formular oder ein Formular mit mehreren Registerkarten zu verwenden.
- Menü – Ein TreeView-Steuerelement sollte ausreichen, um MDI-Formulare auszuwählen
- Formulare – Es besteht die Möglichkeit, gebundene oder ungebundene Formulare zu verwenden.
- Berichte – Crystal Reports oder SQL Server Reporting Services (Business Intelligence Development Studio – wird nicht mehr unterstützt) erstellen Berichte, die den alten Access-Berichten ähneln.
- Es ist weiterhin möglich, eine Access-Datenbank und die Access-Berichte aus VB.Net aufzurufen. Dies kann den Übergangsprozess beschleunigen.
- Tabellen – Diese müssen möglicherweise aufgrund mangelnder Normalisierung oder falscher Indizierung neu gestaltet werden. Das von SQL Server verwendete Standardschemapräfix „dbo_“ muss möglicherweise jedem Tabellennamen hinzugefügt werden.
Implementierung von VBA-Standards
Der Konvertierungsaufwand hängt stark von den Codierungsstandards ab, die von den früheren Access-Programmierern verwendet wurden – und je nach Erfahrung der Programmierer und dem Alter, in dem das System erstmals erstellt wurde, lassen die Standards in der Regel sehr zu wünschen übrig.
Modulcodierungsstandards, die die Konvertierung erleichtern, sollten zunächst im Access-System implementiert werden. Um die spätere Codekonvertierung zu erleichtern, können verschiedene Modifikationen vorgenommen werden:
- Konsistente EinrĂĽckung
- Alle Variablen mit einem Typ deklariert
- Verwenden Sie für Modul- oder globale Variablen das Präfix „m_“ oder „g_“.
- Stellen Sie sicher, dass globale Variablen global benötigt werden
- Legen Sie die Option „Explicit“ in jedem Codemodul fest
- FĂĽgen Sie verwendete, aber nicht deklarierte Variablen hinzu
- FĂĽgen Sie allen Variablen, egal ob dimensioniert oder Parameter, einen Datentyp hinzu
- FĂĽgen Sie allen Funktionen einen RĂĽckgabedatentyp hinzu
- Verwenden Sie Funktionen wie DateAdd für die Datumsarithmetik anstelle von „+“ oder „-“.
- Eliminieren Sie alle Eval-Funktionen
- Vermeiden Sie nach Möglichkeit das „Bang“-Konstrukt – also Forms!Customers!CustomerID
Es wäre hilfreich, wenn Steuerfelder mit beschreibenden Namen anstelle von Text1, Text2 oder Befehl1, Befehl2 umbenannt werden könnten. Leider kann das Ändern eines Feldnamens zu Problemen führen, da auf das Feld möglicherweise in anderen Formularen, Makros, Berichten, Modulen oder Abfragen verwiesen wird. Nach solchen Änderungen wird das Debuggen des Access-Systems normalerweise zu einem Albtraum.
Konvertieren von DAO in ADO oder ADO.Net
DAO-Funktionen wie Recordsets und Querydefs müssen entweder in ADO oder ADO.Net konvertiert werden. ADO.Net hat ADO ersetzt, ADO wird jedoch weiterhin unterstützt. Wenn Sie mit ADO vertraut sind, bleiben Sie dabei – es ist einfacher und genauso effizient wie ADO.Net.
Wer abenteuerlustiger ist, probiert die LINQ-Alternative zu ADO oder ADO.Net aus. Warten Sie jedoch fĂĽr das endgĂĽltige Produktionssystem auf die effizientere Implementierung von LINQ in Visual Studio 2012.
Nach der ersten Umstellung auf VB.Net
- Konstanten benötigen einen Datentyp.
- Alle Variablen in Funktionen oder Unterprogrammen werden standardmäßig mit einem ByVal-Schlüsselwort deklariert. Überall dort, wo ein Wert zurückgegeben werden muss, sollte das Schlüsselwort in ByRef geändert werden.
- Optionale Parameter in Funktions- und Unterroutinen mĂĽssen einen Standardwert haben.
- Konstanten benötigen explizite Datentypen.
- Verwenden Sie Option Strict, um die Effizienz sicherzustellen und Datentypfehler zu vermeiden.
- Deaktivieren Sie „Option Infer“.
Willkommen zu den Freuden von Object Oriented Visual Basic!