CLR (Common Language Runtime) permite sacar gran partido de .NET desde el interior de SQL Server. Funcionalmente hablando, podríamos hablar de Visual Basic como predecesor (aunque muy de lejos) de CLR, ya que Visual Basic convierte su lenguaje en llamadas a API de Windows de bajo nivel…
CLR va mucho más allá que VB, ya que podemos usar código fuente (ficheros .dll, .exe…) y después de compilarlos con .NET, es CLR quien pasa las instrucciones a la CPU y asegura el correcto funcionamiento del código, interactuando con las aplicaciones, en nuestro caso con SQL Server.
Más concretamente, el código fuente es interpretado por MSIL (Microsoft Intermediate Languaage). Y .NET Framework utiliza un compilador JIY (Just In Time) para convertir las instrucciones MSIL en instrucciones específicas para el hardware, instrucciones que CLR pasará a la CPU para que las ejecute.
Cuando ejecutamos una aplicación cualquiera en .NET, CLR solicita los recursos al sistema operativo, por ejemplo, si la aplicación necesita más memoria, CLR solicita la memoria al sistema operativo… Pero cuando trabajamos con CLR integrado en SQL Server, el comportamiento es distinto, ya que es SQL Server quien proporciona los recursos a CLR.
Transact-SQL está diseñado específicamente para el acceso directo a los datos y la manipulación de la base de datos. Aunque T-SQL destaca en el acceso y administración de datos, no es un lenguaje de programación completo. Por ejemplo, no admite collections, for-each loops, bit shifting, o classes. Aunque algunas de estas construcciones se pueden simular en T-SQL, el código que ejecuta CLR tiene compatibilidad integrada para estas construcciones.
El código ejecutado por CLR es más adecuado que T-SQL para los cálculos y la lógica de ejecución complicada y presenta una amplia compatibilidad para muchas tareas complejas, como son el tratamiento de cadenas y las expresiones regulares.
.NET Framework, incluye una biblioteca que tiene acceso a miles de clases y rutinas previamente integradas. Se puede tener acceso a éstas con facilidad desde cualquier procedimiento almacenado, trigger o función definida por el usuario. Por ejemplo la Biblioteca de clases base (BCL) incluye las clases que proporcionan la funcionalidad para la manipulación de cadenas de caracteres, operaciones matemáticas avanzadas, el acceso a archivos, criptografía, etc.
Para compilar código en .NET, existen varias maneras de hacerlo. Una forma de hacerlo es usar Visual Studio, Aquí os dejo un enlace que os ayudará a compilar, administrar y aprender sobre sus aplicaciones, y donde podéis Descarga de evaluación de Visual Studio 2012. Otra alternativa es descargar el último kit de desarrollo de software gratuito de .NET Framework en: SDK (software Development Kit) y así poder utilizar un editor de texto para crear los archivos de código fuente. Desde cualquier lenguaje para el que exista un compilador que genere código para la plataforma .NET es posible utilizar código generado para la misma. La integración de lenguajes es tal que es posible escribir una clase en C# que herede de otra escrita en Visual Basic.NET que, a su vez, herede de otra escrita en C++ .
CLR está desactivada de forma predeterminada en SQL Sever, para activarlo podéis ejecutar:
|
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO |
Si quieres utilizar una función ejecutada por CLR desde SQL, hay que registrar el ensamblado mediante la instrucción CREATE ASSEMBLY
De esta forma SQL podrá acceder a la dll registrada:
|
CREATE ASSEMBLY NombreAssembly
FROM 'C:\Directorio\TuDLL.dll'
WITH PERMISSION_SET = SAFE; |
àLos permisos que puede configurar son:
· SAFE: Solamente código que corre dentro de del proceso de SQL puede ser ejcutado.
· EXTERNAL_ACCESS: Cuando el ensamblado necesita acceso a archivos, redes, variables ambientales y el registry.
· UNSAFE: Cuando el ensamblado necesita acceso no restringido a recursos, tanto dentro como fuera de una instancia de SQL Server.
Con la consulta: SLECT * FROM sys.assemblies podemos verificar si se ha creado el ensamblado.
Y en el caso de querer usarla la dll con una función de SQL, la instrucción CREATE FUNCTION es la encargada de asociar las funciones CLR con las funciones de SQL, con la cláusula EXTERNAL NAME se especifica la función que se quiere utilizar con el formato: Assembly.Class.Method, donde Assembly es el nombre registrado con la instrucción CREATE ASSEMBLY y Class es la clase completa.
Los procedimientos almacenados CLR son muy parecidos a las funciones CLR con unas características adicionales. Características como: devolver un valor, uso de parámetros, pueden devolver mensajes al cliente, también pueden invocar funciones DDL y DML.
De la misma forma crear un procedimiento almacenado que trabajen con CLR, se usa la instrucción CREATE PROCEDURE con la clausula EXTERNAL NAME
|
CREATE PROCEDURE TuPocName
AS
ESTERNAL NAME NombreAssembly.ClassName.MethodName |
También se puede usar .NET para crear trigger CLR, que junto a los tipos de datos usados por CLR, y los objetos que ayudan a integrar .NET con SQL Server nos abren horizontes para el desarrollo en SQL Server.
Fuentes:
Microsoft, msdn, TechNet blog...
Apunte y recopilación por Norman M. Pardell
Puedes consultarme, si deseas cualquier aclaración, pregunta o sugerencia en: Contacto, contestaré tan pronto como me sea posible.
