Edward Peters would like to thank Rob Steward, program manager of ADO.NET, ODBC, OLE DB for DataDirect Technologies, Inc. for contributing this month’s column.

The Microsoft .NET platform has quickly established itself as a viable option for building, deploying and operating XML-based Web services as well as other client and application server-based applications. The rapid adoption of this new technology has left many IT buyers with questions about best practices for .NET development and deployment. This article explores one of the most critical elements of .NET architecture – data access – and explains how the choices you make in this area can have dramatic impacts on application performance, reliability and security.

Many of the strongest advantages of the .NET environment, including enhanced performance, interoperability, scalability and security, underlie .NET's rapid adoption rate. These advantages largely accrue to the use of managed code – code complied for the .NET runtime environment. It runs in the Common Language Runtime (CLR), which is the heart of the .NET Framework. The CLR provides services such as security, memory management and cross-language integration. Managed applications written to take advantage of the features of the CLR perform more efficiently and safely, and take better advantage of developers’ existing expertise in languages that support the .NET Framework.

If you are currently using or considering using the .NET environment, your ability to capitalize on its security, performance and scalability advantages will depend directly on how you choose to access data stored in relational databases. This article will explain why choosing a 100 percent managed ADO.NET data provider is essential to exploiting the best .NET has to offer.


The .NET environment includes many enhanced security features that are extremely attractive to corporate IT buyers. To take advantage of these features, applications must run in a 100 percent managed code environment. Managed code does not have direct access to memory, machine registers or pointers. The .NET Framework security enforces security restrictions on managed code that protects the code and data from being misused or damaged by other code. An administrator can define a security policy to grant or revoke permissions on an enterprise, a machine, an assembly, or a user level. For these reasons, applications that use managed code are much safer.

Code Access Security

Code access security lets the administrator specify which operations a piece of code can perform, stopping inappropriate behavior before it can start. You can configure a complex set of rules that specify whether a code group can both read and write files, demand that the code’s callers have specific permissions, allow only callers from a particular organization or site to call the code, grant permissions to each assembly that is loaded and compare the granted permissions of every caller on the call stack at runtime to the permissions that callers must have and which resources the code can access.

The access privileges an administrator assigns depend in part on where the application is running. For example, by default, an application that runs from the local computer has a higher level of trust and more privileges, such as accessing the file system, than an application that is running from the Internet.

Calling unmanaged code bypasses the .NET CLR security. An application that calls unmanaged code doesn't necessarily have a security problem – it simply has an open door to the possibility of problems due to the functionality of the unmanaged code that has direct access to memory or machine registers or uses pointers. Once the unmanaged code is being executed, the CLR can no longer check it.

Avoiding Buffer Overruns

One common type of attack attempts to make API methods operate out of specification, causing a buffer overrun. This attack typically passes unexpected parameters, such as an out-of-range index or offset value. Managed code avoids the buffer overruns that trigger so many security breaches.

Buffer overruns usually occur in programs written in languages such as C or C++, which do not check array bounds and type safety. If an application does not check the validity of the destination buffer size and other parameters, the copied data might overrun the buffer, overwriting the data in adjacent addresses.

Due to the structure of the .NET environment and the security features available, buffer overruns are theoretically impossible in managed code.


The .NET CLR was designed from the start to provide good performance. By using 100 percent managed code, developers can take full advantage of the numerous built-in services of the CLR to enhance the performance of your managed application. In addition, by using 100 percent managed code, developers will eliminate the performance costs associated with calling unmanaged code.

The .NET Framework includes both an ODBC data provider and an OLE DB data provider that enable developers to get started developing applications with existing data sources. These providers, however, are technology "bridge" solutions that rely on underlying ODBC drivers and OLE DB providers to do the real work. The bridges must call unmanaged code (code outside of the .NET environment), which has a significant performance cost because they must translate from ADO.NET interfaces to the underlying ODBC or OLE DB APIs. There are always limitations incurred when translating from one API to another. For these reasons, bridge solutions are suboptimal and are not recommended for applications where performance is critical.

If security and performance are critical, managed code is imperative to the .NET environment. When using data connectivity built from 100 percent managed code, you are ensured that no outside influence can negatively impact the performance and security of your code. Managed code also receives the benefit of automatic versioning. .NET executables can be to run only with the same versions of external components with which they are built. This allows for side-by-side implementations of DLLs without having to worry about conflicts.

On the other hand, unmanaged code is code that is executed directly by the operating system, outside of the CLR. Because it does not run inside the .NET environment, unmanaged code cannot make use of any .NET managed facilities. Unmanaged code also impacts performance, as there are additional checks made at runtime as the application bridges out of the CLR.

When choosing between managed and unmanaged code, the choice should be clear. If scalability, performance and security are important pieces of your application, then managed code should be the method of implementation. It is important to remember that because an application is developed as managed code, this does not mean that it is. A managed application that uses components that are unmanaged will not receive the full benefits of fully managed code within the .NET Framework. It is imperative that developers look for ADO.NET data providers that are 100 percent managed code.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access