MS SQL Server
  Home arrow MS SQL Server arrow Page 2 - Implementing Managed code in SQL Server 20...
ASP Free Forums 
.NET  
ASP  
ASP Code  
ASP.NET  
ASP.NET Code  
BrainDump  
C#  
Code Examples  
Database  
Database Code  
IIS  
Microsoft Access  
MS SQL Server  
Visual Basic.NET  
Windows Scripting  
Windows Security  
XML  
ASP Web Hosting  
ASP.NET Web Hosting 
Dedicated Servers 
Moblin 
JMSL Numerical Library 
Windows Web Hosting
 
IBM® developerWorks 
Sun Developer Network 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
MS SQL SERVER

Implementing Managed code in SQL Server 2005 using Visual Studio.NET 2005
By: Jagadish Chaterjee
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 20
    2005-05-09

    Table of Contents:
  • Implementing Managed code in SQL Server 2005 using Visual Studio.NET 2005
  • Introduction to Managed Code
  • Creating Managed Code using Visual Studio.NET 2005
  • Executing the Managed Code from Visual Studio 2005
  • Transact SQL vs. Managed Code

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Implementing Managed code in SQL Server 2005 using Visual Studio.NET 2005 - Introduction to Managed Code


    (Page 2 of 5 )

     

    The code that gets executed in a "managed" environment is referred to as Managed Code.  Code that you develop with a language compiler that targets the runtime (in this case, it is CLR) is called managed code; it benefits from features such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services. 

    Managed and unmanaged programming models are dissimilar in many respects. The following figure (Fig 1) shows the defining characteristics of each model.

    The following sections explain each of those characteristics in more detail.

    Coding models

    Unmanaged objects always communicate through interfaces; managed objects and classes can pass data directly without implementing interfaces. By default, COM interop generates a class interface to expose managed functionality through an interface to COM when the object or class does not implement one. 

    Error handling mechanisms

    COM methods usually return an HRESULT, indicating that the call succeeded or failed. Managed code incorporates exceptions. By default, COM interop maps managed exceptions to failure HRESULTs. 

    Identities

    GUIDs identify a specific unmanaged type and provide no location information for that type. Strong names consist of a unique assembly name in addition to a type name. Because the assembly name uniquely identifies the type, you can reuse a type name across multiple assemblies. An assembly also introduces publisher key, version, and location information to a managed type. Interoperation services generate GUIDs and are strong-named as required. 

    Type compatibility

    Types vary between managed and unmanaged code, and also among languages. 

    Type definitions

    If you are accustomed to working with type libraries, you know that they contain only public types. Moreover, a type library is optional. In the managed programming model, type information is mandatory for all types. Interoperation services provide tools that convert type libraries to metadata in assemblies, and metadata to type libraries. 

    Type safety

    Unmanaged compilers provide no type checking on pointer types, making the code susceptible to potentially harmful activity. In general, managed code requires a higher level of trust. Programmers can continue to use pointers in managed code, although the code has restrictions due to its unsafe behavior. Interoperation services prevent untrusted, managed code from accessing unmanaged code. 

    Versioning

    COM interfaces are immutable. If you change an interface, you must rename it with a new GUID. Managed types can evolve, keeping the same name. 

    We have covered CLR, Managed Code and other terms. Let us examine the practical way of implementing Managed Code inside the SQL Server 2005 database. 

    More MS SQL Server Articles
    More By Jagadish Chaterjee


       · It is a very good article to start with.The tabular difference between managed and...
     

    MS SQL SERVER ARTICLES

    - Completing the Introduction to Transact-SQL
    - A Brief Introduction to Transact-SQL
    - Lookups and Blocking Bad Data
    - Field Validation Rules for Blocking Bad Data
    - Using Masks to Block Bad Data
    - Blocking Bad Data
    - Using @@ROWCOUNT and TABLE Variables for Dat...
    - How to Use Variables, IF and CASE in Databas...
    - Creating Important Aspects of Notification S...
    - Working wth Variables in Database Interactio...
    - Delving Deeper into Notification Services
    - Notification Services
    - Building a Multi-table Report with SQL 2005 ...
    - A Secure Way of Building Connection Strings
    - Transferring a Database Using the SSIS Desig...





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 2 hosted by Hostway