Navigation:  Articles > Aug-2002 >

Access, Office, and .NET

Previous pageReturn to chapter overviewNext page

Peter Vogel        

The question I used to get asked most often was “Will SQL Server replace Access?” As I suggested in my March 2002 editorial, the question reallyshould be “Will SQL Server replace Jet?” and the answer is “Sure. Probably. If you need it.” I’m not being asked that question as frequently. Instead, the question that I get these days is “What is .NET going to do to Access?”

ad6468x60

Since I don’t get memos on these topics from the people at Microsoft (we’re an independent newsletter written by people who love Access), I can only give you my opinion. At the very least, I can give you a way of looking at the problem. In my view, there are three questions here:

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?

I’m actually going to answer these questions in the next issue. This month, I just want to lay the groundwork by making sure that we all mean the same thing when I start talking about what the .NET Framework is. So this month, I’m going to give you my view on .NET, and next month I’ll share my view on where Access fits in the world created by .NET. One more step: Before discussing what Microsoft’s .NET Framework is all about, I’ve got to go back to how programs work with Windows.

In Windows, your programs don’t do most of what they do. When, for instance, a program draws a form on the screen, it’s not code in the program that draws the box. Instead, the program’s code issues a call to a standard Windows routine that draws the box. When you compile an Access program (or a Visual Basic program), the compiler produces the code that calls the Windows routines. Even that isn’t completely true, but I’ll correct that near the end of this editorial.

Coming back to .NET, one way to look at the .NET Framework is that it just provides a new set of standard routines to call. Compilers for the .NET Framework read your source code and produce compiled code that includes calls to the .NET standard routines. A program compiled for the .NET Framework (a “.NET program”) needs and expects these routines to be present.
 
What’s important about these standard routines is the way that they’re exposed to the programs that depend on them: the interface to these routines. What’s behind that interface is irrelevant to the programs that use the routines—the programs depend only on the interface to the standard routines. This is what, in theory, can make the .NET Framework a cross-platform environment. Presumably, someone can remove the current Windows/Intel-specific code from the .NET standard routines and then re-implement the routines using code appropriate for some other host environment—Linux leaps to mind.

To complete this process, you have to control when (and to what extent) your program is compiled. If your code is, for instance, compiled to Windows/Intel code, then your program can only run on Windows/Intel computers, even if it’s calling to the .NET standard routines. So, while the .NET platform is (potentially) cross-platform, .NET programs might not be. The trick to making your programs cross-platform is to not compile programs to run on any particular platform. A .NET compiler initially compiles your source code to Intermediate Language (IL), which is guaranteed not to run on any computer or operating system.

Access and older Visual Basic programmers will recognize this strategy. When Access compiles your source code, it compiles it to pseudo-code, not to Intel machine code. Up until Visual Basic 5, Visual Basic worked the same way: Code was compiled to pseudocode, not to real machine code. When an Access or Visual Basic 4 program is run, it is interpreted by a master program that translates between the pseudocode and Windows. If you want, you can still choose to compile your Visual Basic 6 code to pseudo-code, though there isn’t a lot of benefit to this (pseudo-code “executables” are generally smaller but run slower).

The .NET Framework could provide the same facility: Compile to pseudo-code and interpret it at runtime. Instead, however, what’s currently provided is a set of compilers that translate your program from IL to Windows/Intel-specific code. This second pass compiler can be invoked at a number of different places: immediately after the program is compiled to IL, when the program is installed on the computer that it’s to run on, just before the program is run for the first time, or just before the program is run every time the program is run. The last two options are frequently referred to as JIT (Just-In-Time) compilation. A program compiled into IL can be moved to

any computer and, once there, compiled to the language specific to a particular computer. Once there, the program can be compiled to the appropriate language and the program can execute, calling the version of the .NET Framework routines installed on that computer.

That wraps up my discussion of .NET. Next time, what it means to Access developers.

 

For complex SQL Server upsizing projects and .Net Conversions, Garry's company Sells the MUST upsizing tool.
Find out more on upsizing and .Net Conversions from Access here http://www.vb123.com.au/up/

 

 

See next months editorial on Access and .NET