In Newsgroups, Foren und bei Access-Stammtischen wird immer wieder die Frage gestellt, wie es mit Microsoft weitergeht. Wie lange gibt es das noch? Soll ich zu .NET wechseln? Welche Zielgruppe hat Access überhaupt?

Mit der neuesten Version, die unter dem Namen Access 2007 läuft, hat Microsoft mehr für Verunsicherung denn für Sicherheit gesorgt. Viele professionelle Access-Entwickler arbeiten erst gar nicht damit, weil es aus ihrer Sicht eher ein Spielzeug für Quereinsteiger aus dem Excel-Lager geworden ist und attestieren der neuen Version viele Veränderungen, die Profis wenig nützen. Die mangelnde Bereitschaft und Gelegenheit, selbst einmal einen ausgiebigen Blick auf die Features der neuen Version zu werfen, scheint gerade unter fortgeschrittenen Access-Entwicklern sehr ausgeprägt zu sein - andererseits muss man aber auch sagen, dass die 2007er-Version schon eine ganze Reihe Bugs mitliefert.

Insgesamt sorgten gerade in Zusammenhang mit Access 2007 drei Punkte für das Auftauchen von Fragen über die Zukunft von Access:

• Microsoft empfiehlt für den Zugriff auf den SQL Server nunmehr ODBC und keine Access-Projekte (ADPs) mehr.
• Microsoft stattet Access mehr und mehr mit Features aus, die den Einstieg und das Erstellen einfacher Datenbankanwendungen erleichtern.
• Gleichzeitig gibt es so gut wie keine neuen Features für professionelle Entwickler. Oder doch? Zumindest wird VBA  genausowenig weiterentwickelt wie die .NET-Programmiersprachen Einzug in Access halten.
• Microsoft bietet die Runtime-Version für Access 2007 und die Developer Extensions kostenlos an.

ADP und ODBC

Microsoft empfiehlt, Access-Anwendungen mit den im SQL Server enthaltenen Tabellen einer Datenbank via ODBC zu verknüpfen anstatt ADPs zu verwenden ( aus [2]: “To take maximum advantage of the new features in Office Access 2007, Microsoft recommends the use of linked tables to connect to SQL Server data.”). Schaut man sich die Möglichkeiten zum Anlegen neuer Datenbankdateien unter Access 2007 an, ist dort entgegen erster Gerüchte neben ACCDBs und MDBs auch noch die ADPs aufgeführt. Legt man ein solches an, stellt man aber durch einen Blick auf die Titelleiste der Anwendung schnell fest, dass man soeben ein Projekt im Dateiformat von Access 2002/2003 angelegt hat. ADPs und das neue Dateiformat lassen sich nicht kombinieren, was zumindest bezüglich der Weiterentwicklung von ADPS ein klares Signal gibt. Der Grund wird schnell deutlich, wenn man sich die neuen Features von Access 2007 ansieht und worauf einige davon abzielen: So gibt es etwa neuen Datentypen, die auf den Einsatz mit Microsoft Sharepoint zugeschnitten sind, aber mit dem SQL Server nicht verwendet werden können - und dies wird direkt unterbunden, indem man das Access 2007-Dateiformat gar nicht erst mit ADPs kombinieren kann.

Von Excel zu Access

In [2] schreibt Microsoft: “Office Access 2007 will make the creation of native Access tables more intuitive, especially for users who are familiar with Excel.” Das stinkt etablierten Access-Entwicklern, die Angst haben, dass Access zum “Spielzeug” verkommt. Der Grund ist nicht, dass sie die eine oder andere Vereinfachung etwa bei der Erstellung von Tabellen oder dem Verwalten von Objekten wie Bildern oder Dateien in Access-Tabellen nicht wollten, sondern dass sich ein Bild in der Allgemeinheit und vor allem bei Kunden entwickeln könnte, dass Access nicht mehr als vollwertiges und seriöses Produkt zur Entwicklung professioneller Datenbankanwendungen wahrgenommen wird.

Dies ist aber auch nur die negative Seite dieser “Vereinfachungen” durch die neuartigen Database-Templates, noch einfachere Tabellen-Erstellung und noch mehr Assistenten zum Zusammenklicken von Formularen und Berichten. Es gibt auch eine positive Seite. Je einfacher der Einstieg in die Erstellung von Datenbankanwendungen mit Access wird, desto mehr Leute sehen sich auch berufen, dort selbst Hand anzulegen. Bis - ja, bis irgendwann einmal der Punkt erreicht ist, an dem es nicht mehr weitergeht, weil entweder die Kenntnisse nicht mehr zum Hinzufügen von VBA-gesteuerten Funktionen reichen oder weil man es satt hat, zum x-ten Male das Datenmodell und sämtliche darauf aufbauenden Objekte wie Abfragen, Formulare und Berichte anzupassen, weil man hier mangels Erfahrung in der Datenmodellierung einfach nicht direkt zu ausreichend guten Ergebnissen kommt. Und dort schlägt nun doch noch die Stunde der Profi-Entwickler: Die dürfen nämlich dann ausbügeln oder weiterentwickeln, was Microsoft durch seine Politik des “leichten Einstiegs” und ambitionierte Access-Quereinsteiger produziert haben und kommen so halt ein wenig anders zu ihrem Recht. ;-)

Hochnäsigkeit gegenüber den neuen, einsteigerfreundlichen Features ist ohnehin nicht angezeigt, dürfte doch ein Großteil der heute fortgeschrittenen Entwickler ebenfalls einen leichten Einstieg in die Datenbankentwicklung mit Access gefunden haben, indem er sich seinerzeit für diese Anwendung statt etwa für eine Programmiersprache wie VB6 etc. entschieden hat. Die dürften nämlich damals auch die Access-Entwickler mit ihren datengebundenen Formularen und Steuerelementen herabgeblickt haben …

Der Sharepoint-Faktor

Wer Microsoft in den letzten Jahren beobachtet hat, dürfte bemerkt haben, dass sich Sharepoint zum Lieblingskind entwickelt hat. Böse Zungen behaupten, Sharepoint wäre zunächst nur intern verwendet worden und man hätte sich dann entschlossen, auch den Rest der Welt an den großten Vorteilen dieser Anwendung teilhaben zu lassen - und dafür tut Microsoft eine ganze Menge. Ein Beispiel ist eben die Integration von Sharepoint und Access - wenn auch zunächst nur sehr zärtliche Bande geknüpft wird, indem man von Access aus auf die sogenannten Sharepoint-Listen zugreifen kann und einige neue und zu Sharepoint kompatible Datentypen eingeführt werden. Und wenn man eins und eins zusammenzählt, wird klar, dass die Zusammenarbeit zwischen Access und Sharepoint nicht wirklich ein Hinweis auf ein Dahinsiechen von Access ist. Naja, vielleicht verändert es sich in Zukunft ein wenig …

Entwickler-Features

Access 2007 liefert einige Erleichterungen für den Einstieg, das steht fest. Viele sehen aber darüber hinweg, dass es auch interessante Möglichkeiten gibt, die fortgeschrittenen Entwicklern die Arbeit erleichtern - hier und da besteht zwar noch Nachbesserungsbedarf, aber das gab es auch in früheren Access-Versionen.

• Ein Beispiel ist die Möglichkeit, Steuerelemente in Formularen zu verankern und deren Größe an die des Formulars anpassen zu lassen - man braucht also keine Krücke mehr zu programmieren, die beim “Bei Größenänderung”-Ereignis in mühseliger Kleinarbeit die entsprechenden Eigenschaften der Steuerelemente anpasst.
• Mit dem Ribbon liefert Access ein Feature, dass geradezu eine Herausforderung für Access-Profis ist: Hier wird nicht mehr mit dem langweiligen Anpassen-Dialog für Menüs gearbeitet, sondern das Ribbon basiert auf XML und muss von A bis Z selbst programmiert werden!
• Das Wegfallen des Sicherheitssystems kann man positiv wie negativ sehen: Es war nie wirklich sicher und gaukelte unwissenden Entwicklern vor, ihre Daten ausreichend zu schützen. Wer seine Daten wirklich schützen möchte, muss nun den SQL Server oder eine ähnliche Software verwenden. Schade ist das Wegfallen dieses Systems, weil es vielen nicht als Sicherheitsgarant, sondern als Tool zur Benutzerverwaltung diente - mit dem einzigen Hintergrund, dem Benutzer abhängig von seinem Status die entsprechenden Elemente der Benutzeroberfläche freizuschalten. Eine solche Funktion muss man nun ebenfalls händisch hinzufügen.
• Text- und Memofelder können nun Richtext aufnehmen. Dieser wird durchgängig in Formularen und auch in Berichten angezeigt und könnte so für viele Anwendungsfälle speziell für diesen Zweck entwickelte Steuerelemente ablösen.
• Schaltflächen nehmen nun nicht nur Texte oder Bilder, sondern beides gleichzeitig auf! Somit entfallen Basteleien und der Einsatz von Nicht-Standard-Steuerelementen von Access.
• Tabellen lassen sich nun wie auch die in Formularen und Berichten dargestellten Daten mit alternierenden Hintergründen ausstatten.
• Formulare und Berichte bieten eine ganze Reihe von Erleichterungen für das Layouten der Steuerelemente, die nicht nur Einsteigern das Leben erleichtern können.
• Und schließlich wird auch die Berichtsansicht ihre Freunde finden, denn Sie kann - mit einigen Einschränkungen - quasi als Formular mit flexibler Detailbereichhöhe eingesetzt werden.

Runtime und Developer Extensions

Zugegeben: Gerade die Developer Extensions kann man derzeit wohl eher noch als Beta bezeichnen. Wer allerdings einmal ein wenig mit der Runtime experimentiert hat, kann frohlocken: Immerhin erlaubt die Access 2007-Runtime - zumindest technisch - das Starten beliebiger Access-Anwendungen von der Version 2000 bis zur Version 2003. Das Ribbon ist dabei kein Pflichtprogramm, Anwendungen älterer Versionen (und sogar 2007er-Exemplare) stellen ohne Probleme eigene Menüleisten zur Verfügung. Ob dies nun erlaubt ist, mag jeder selbst mit sich und den Lizenzbedingungen von Microsoft ausmachen, die beispielsweise folgendes zu Tage bringen:

“You may not 

• […]
• keep the status bar containing the statement “Powered by Microsoft Office Access” displayed in your user interface to be viewed by users at all times;
• identify Microsoft as the source of the Microsoft Office Access 2007 Runtime software in your programs’ About Box;
• distribute the Microsoft Office logo as part of and as it appears in the Microsoft Office Access 2007 Runtime software without any changes to it;”

Wenn der hier aufgeführte letzte Punkt bedeutet, dass die Office-Schaltfläche immer sichtbar sein muss, würde das natürlich die Verwendung eigener (alter) Menüs einschränken. Aber ob das so gemeint ist?

Von Access zu .NET?

Der Einzug von .NET-Sprachen ist nun zunächst um mindestens eine Version hinausgeschoben, und er wird wohl so schnell auch nicht kommen: VBA ist mit seinen zahlreichen Bibliotheken und im Bunde mit Access ein prima Team. Als Entwickler muss man sich ernsthaft fragen, wo hier Platz für .NET-Elemente sein soll. Und wenn das doch der Fall sein sollte, baut man halt ein .NET-Add-In und setzt es zusammen mit Access ein - alternativ kann es natürlich auch eine COM-DLL sein.

Und von Access zu .NET wechseln? Das wird wohl kein Entwickler tun, wenn nicht das Ende von Access definitiv bevorstünde. Und dafür spricht nun wirklich nicht viel.

Zielgruppe

Die Zielgruppe für die mit Access entwickelten Anwendungen hat sich nicht verändert. Durch Features wie etwa die Custom Task Panes gibt es eher noch weitere mögliche Anwendungsbereiche, die sich verstärkt auf die Office-Integration konzentrieren. Was die Benutzer von Access selbst angeht, so kann Microsoft noch so viele vereinfachende Elemente wie Vorlagen, Assistenten und Co. hinzufügen: Das Entwickeln von professionellen Datenbankanwendungen wird fortgeschrittenen Access-Benutzern vorbehalten bleiben. Dementsprechend wird sich möglicherweise die Anzahl der Benutzer, die sich auf die Schnelle mal eine Datenbank aus einer Vorlage erstellen, zwar größer werden, dies geht aber sicherlich nicht zu Lasten der professionellen Entwickler. Denn irgendwer muss die per Vorlage erstellten Anwendungen ja auch anpassen.

Weitere Informationen:

[1] Optimizing Microsoft Office Access Applications Linked to SQL Server, http://msdn2.microsoft.com/en-us/library/bb188204.aspx

[2] Microsoft Office Access vision white paper, http://office.microsoft.com/en-us/access/HA102133061033.aspx

[3] Migration considerations for Access 2007, http://technet2.microsoft.com/Office/en-us/library/1dce641e-ba1c-446a-8ff2-221769a58ba51033.mspx?mfr=true