Navigation:  Articles > Sep-2002 >

Access and .NET

Previous pageReturn to chapter overviewNext page

LAST month, I began discussing the impact that I’d expect .NET to have on Access. I spent all of last month outlining my understanding of .NET and trying to position .NET within the technologies that you’re probably already familiar with. I also suggested that the big question of “What will .NET do to Access?” boils down to these three questions:

1. What’s the future for VBA in a .NET world?

2. What’s the future for Access (and Microsoft Office) in a .NET world?

3. Can ADO.NET and Access work together?

Starting with the first question: The interop functionality in .NET allows you to use COM objects from .NET applications. As a result, I don’t see any reason why I shouldn’t be able to check off Access in the references list of a .NET application and then use Access through Automation the same way that I would do now from a Visual Basic program. While I say, “I don’t see any reason,” that doesn’t mean that you can actually do it. At least with Access 2002, attempting to add a reference to Access generates a message that complains about the Office Web Components and ADODB. Still, it doesn’t sound like a problem that can’t be fixed either in .NET, the next version of Access, or both.

If I can automate Access from a .NET application, it seems at least possible that developers could be given the choice to create Access applications using either VBA or .NET. Choosing .NET wouldn’t be pretty since it would almost certainly involve creating a separate EXE (in Intermediate Language) that would have to travel with the Access application. Currently, all of your VBA (in pseudo-code) is stored into your MDB file as a single large object. This makes saving changes to your VBA code slow, but it also means that when you move your forms/ reports/queries, that you’re also moving your code.

It seems to me that it is, then, at least possible for VBA and .NET coding languages to co-exist in some version of a COM-based Access. Macros and VBA currently co-exist in Access and, as I remember, WordBasic and VBA co-existed in Word for one version. Microsoft has promised to support using .NET languages to create stored procedures in a future version of SQL Server, and I’d be very surprised if this meant dropping support for the current stored procedure language, T-SQL.

However, it seems unlikely to me that anyone outside of Redmond would consider this a great feature. Just because it can be done doesn’t mean it should be done. Which leads to the next question: the future of Access

(and Office) in a .NET world. There’s nothing stopping Microsoft from rewriting Office into some .NET language and then compiling Office into Intermediate Language. That would position Office to run on any operating system that has a version of the .NET platform installed. The rewrite wouldn’t be trivial, but Microsoft hasn’t balked at significant rewrites in the past. Some functionality might be lost or altered, depending on how well .NET supports the features of Windows that Office depends upon.

If one of the goals of the .NET strategy is to open every platform in the world to Microsoft products, rewriting Office for .NET would make strategic sense. The .NET interop functionality does allow COM-based code to interact with .NET objects so, presumably, it’d be possible for VBA code to co-exist with .NET in “Office.NET,” at least on Windows platforms. Since it’s impossible to convert existing VBA code to .NET (no matter what you may have heard), failing to provide VBA support in Office.NET would significantly delay acceptance of the product on the Windows platform. However, if Microsoft is willing to use Office.NET to jumpstart Office development on non-Windows platforms, abandoning VBA might be a price that Microsoft would be willing to pay. Microsoft has demonstrated with .NET that backwards-compatibility isn’t the overriding concern that it used to be.

The final question is whether ADO.NET could be supported in Access. Certainly, if Access is rewritten to .NET, ADO.NET would be the data strategy that “Access.NET” would support. If you’ve been excited about using disconnected recordsets with forms in Access and frustrated with their limitations, a marriage between Access and ADO.NET (where disconnected databases are fundamental to the data architecture) would be very desirable. Using ADO.NET with a COM-based version of Access is unlikely (I’d say impossible, but nothing in software is impossible—it just takes longer and runs slower). By the time that the Access forms, reports, and queries were modified to work with ADO.NET (through the interop classes) it would have been easier just to convert Access to .NET.

What does it mean to you? It seems to me that the real possibility is that Microsoft will come out with a version of Access rewritten to the .NET platform and using ADO.NET. At that point, you’ll need to consider learning some .NET language (I’d recommend Visual Basic .NET— it’s not really all that different) and ADO.NET. There will be a long period of time (measured in years) where both the Windows and .NET versions of Access would be available. And, given Access’s history, it will be Office.NET version 2.0 before the product actually starts to work. Worry about it then.

Does this mean that Access won’t change unless Microsoft commits to a complete rewrite? Not at all. It does mean that the most significant changes will probably come from outside Access. One technology that I can see having a significant impact on Access is SharePoint Services, which is why this month’s and next month’s issues include articles on SharePoint. This isn’t as far-fetched as it sounds: Both Access and SharePoint are about retrieving data. Who knows where a marriage of these two could go? Perhaps Access can move beyond just relational data to handle any data at all.

See last months editorial on Access, Office, and .NET