Lluís Franco on Geeks.ms

Alucina: Premiado C# MVP of the year!

Lluis Franco — Wed, 15 Feb 2012 09:06:08 GMT

Sorprendido. Perplejo. Flipado. Esas son ahora mismo las palabras que mejor pueden definir mi estado actual.

No obstante, a medida que voy escribiendo estas líneas y lo voy realizando voy experimentando una alegría enorme, que ya está se empezando a transformar en una sonrisa beatífica, por no decir estúpida. Y es que he recibido un mail de Lisa Feigenbaum (Microsoft Community Program Manager) con un mensaje que dice:

“Congratulations on being awarded C# MVP of the Year based on your contributions in 2011!”

WOW! Mola mucho, aunque la verdad y aunque suene a tópico no me lo esperaba ni de coña...

Durante los últimos 9 años he tenido la suerte de ser reconocido como Microsoft MVP y eso es algo que valoro mucho. No tanto por ser reconocido como ‘experto’ (cuesta mucho emplear esa palabra habiendo gente tan condenadamente buena), sino por el hecho que se reconozca la labor de ayudar a la comunidad. Que al fin y al cabo es lo que debería contar en el programa MVP, y -seamos sinceros- no siempre es lo único que cuenta.

Pues bien, ahora resulta que en una votación entre los 234 compañeros MVP de la categoría de C# repartidos por todo el mundo y el equipo de producto han decidido nombrarme MVP de C# del año, sea lo que sea eso, que la verdad, todavía no lo tengo muy claro.

De entrada el próximo 2 de Marzo, hay una cena en Seattle con S. Somasegar (“Soma”), Senior Vice President de la división de desarrollo en Microsoft, así como otros peces gordos y miembros destacados de la comunidad. Para mi desgracia, no voy a poder asistir pues vuelvo de Seattle en mismo día por la mañana pero durante mi estancia en el campus de Microsoft trataré de al menos tomarme una cerveza con alguno de estos personajes :-)

Desde aquí quiero dar la enhorabuena al resto de premiados (he contado 29 en todas las categorías) y a todos mis compañeros. De verdad gente, sois grandes! :-D

Un abrazo a todos,

PD – La semana que viene ya os empezaré a contar mis batallitas en Seattle, en directo.

Parallel Series: La clase estática Parallel

Lluis Franco — Tue, 14 Feb 2012 10:32:46 GMT

Acabo de publicar otro post relacionado con las ‘Parallel Series’:

3 métodos para los reyes elfos bajo el cielo

Hoy quiero hablaros de la clase estática Parallel. Esta clase provee soporte para paralelizar bucles y regiones, y al igual que PLINQ su uso es muy sencillo. Cabe destacar que está especialmente optimizada para iteraciones, y que en este contexto se desenvuelve un poco mejor que PLINQ. No hay una diferencia significativa en tiempos absolutos, pero puede verse perfectamente si utilizamos el magnífico profiler de Visual Studio 2010. No obstante, pueden existir situaciones en las que si se necesita afinar mucho el rendimiento en iteraciones, y aquí es dónde tiene más sentido utilizar dos de los tres métodos de esta clase: For y ForEach. Al tercero lo llamaremos Cirdan y apenas aparecerá en esta historia (en realidad me refiero a Invoke pero tampoco aparecerá por aquí)...

Podéis acceder al artículo completo aquí:

http://lluisfranco.com/2011/06/26/parallel-series-la-clase-esttica-parallel/

Un saludo,

Parallel Series: Video – 02 PLINQ

Lluis Franco — Mon, 13 Feb 2012 08:44:29 GMT

Acabo de publicar otro vídeo de las las ‘Parallel Series’. Os dejo aquí también el enlace:

http://lluisfranco.wordpress.com/2011/07/01/parallel-series-video-02-plinq/

En este segundo vídeo de las Parallel Series haremos un breve recorrido por las principales características de Parallel LINQ.

Un saludo,

Luces, cámara… Action!

Lluis Franco — Fri, 10 Feb 2012 16:30:11 GMT

Acabo de publicar otro post relacionado con las ‘Parallel Series’. Os dejo aquí también el enlace:

http://lluisfranco.com/2012/02/08/luces-camara-action/

Un saludo,

Nacen las Parallel Series

Lluis Franco — Wed, 08 Feb 2012 12:55:00 GMT

Como ya os prometí a algunos de vosotros, he empezado a publicar una nueva serie que promete ser la más larga de las que he publicado hasta ahora. El tema a tratar va a ser la programación paralela mediante la Task Parallel Library incorporada en .NET 4.0 y Visual Studio 2010.

Cuento con la ventaja de haber estado creando material durante el último año y medio, en el que he publicado algunos documentos, varios vídeos y hasta un webcast con los chicos de SecondNug. Todo este material y alguno más que tengo en mente formará parte de las Parallel Series, que serán publicadas en mi otro blog y no aquí, porque la publicación cruzada entre WordPress y Community Server es un autentico drama.

Sin embargo, prometo avisar aquí cada vez que publique un nuevo post se la serie. De momento tengo unos cinco o seis artículos publicados (la serie posiblemente llegará a los 20) y mi intención es ir publicando al menos uno por semana, y si puedo dos mucho mejor :-)

Os dejo con el índice de contenidos de la serie:

Índice de contenidos

Y algunos de los artículos ya publicados (y los que faltan):

Índice de contenidos de las Parellel Series

El Alfa (Prólogo)
Un poco de historia
Aclarando conceptos base
Video: 01 Bases
PLINQ: Parallel LINQ
Video: 02 PLINQ
Parallel static class
Video: 03 Parallel Class
Tasks, la 8ª maravilla
Video: 04 Tasks
Problemas de concurrencia
Video: 05 Concurrent collections
El depurador: Tu fiel amigo
Video: Debugging & profiling
Webcast con los chicos de SecondNug
Materiales y presentaciones de mis eventos
C# futures: async & await

Artículos relacionados

A medida que vaya publicando en el otro blog iré actualizando también este de aquí.

Un saludo!

PD – Me encantaría recibir feedback vuestro, así que se agradecerán comentarios de todo tipo (en el otro blog).

Abandona tus DataSets. Ellos no van a tener piedad de ti.

Lluis Franco — Wed, 28 Dec 2011 12:25:00 GMT

¿Todavía estás usando DataSets en tu aplicación .NET?

¿Eres consciente de que los DataSets son actualmente unas pésimas herramientas para trabajar con datos?

¿No utilizas tecnologías más modernas porque te falta capacitación para ello?

Entonces estás de enhorabuena! :-D

Hartos como estamos del uso de los infames DataSets, Pedro Hurtado, un servidor y otros compañeros, con la colaboración de Microsoft, hemos decidido crear un concurso en el que los ganadores podrán acceder a capacitación gratuita, para de este modo poder utilizar las tecnologías más modernas en sus aplicaciones: LINQ to SQL, Entity Framework 4.0, NHibernate o incluso RDO.Resultsets.

Para acceder al concurso basta con participar en esta encuesta (son sólo unas pocas preguntas):

http://apps.facebook.com/mis-encuestas/535kd442

Sólo necesitas un par de minutos y podrás acceder al sorteo.

Anímate y no tengas piedad de los DataSets… Ellos no la van a tener contigo :-)

*** Edición: <comunicado de los organizadores de la broma> ***

Hola de nuevo,

Bueno transcurrido el tiempo de finalización del concurso de "Matemos al DataSet". El ganador para optar a la capacitación es Leandro Tuttini (aunque realmente no la necesite), puesto que nadie más que el se dio cuenta de que se trataba de una bonita inocentada. ¿O es que los dataset os tienen tan inmersos en exception que nadie sabía que ayer en España era 28 de Diciembre de 2011, dia de los Santos Inocentes?

La broma estaba oculta en este parrafo:

"...para de este modo poder utilizar las tecnologías más modernas en sus aplicaciones: LINQ to SQL, Entity Framework 4.0, NHibernate o incluso RDO.Resultsets."

Y como bien mencionó Leandro, los ResultSets de RDO son antiguos artefactos de Visual Basic, anteriores incluso a los RecordSets de ADO.

En fin, feliz día de los santos inocentes++;

Nota personal: Viendo el debate y la atención que se ha creado, creo que podría ser interesante plantearnos ayudar a todos aquellos que deseen conocer estos artefactos del diablo que son los DataSets (eso desgraciadamente, no es ninguna inocentada).

Como lo veis? :-D

Xbox 720 integrará Kinect con Windows Phone de forma nativa

Lluis Franco — Wed, 28 Dec 2011 08:12:00 GMT

Hola a todos,

Se está hablando mucho de la próxima consola Xbox, la llamada 720 que supuestamente aparecerá en verano del año que viene.

Una de las características más esperadas será la total integración con Windows Phone (ya veremos si Apollo, 8 o como quiera que se llame entonces), permitiendo jugar partidas simultáneas en ambos dispositivos, usarlo como mando, o usar la propia Xbox (o más bien el dispositivo sensor de movimiento Kinect) para realizar acciones típicas del teléfono.

Por ejemplo, será posible iniciar una llamada por voz o utilizando gestures, y lo más divertido es que éstos podrán personalizarse en función del contacto. De este modo, podríamos hacer una llamada a casa de un amigo rascándonos una oreja, o levantando el pulgar. Aunque sin duda lo más divertido puede ser cortar una llamada indeseada haciendo una ‘peineta’.

En fin, un mundo nuevo de posibilidades, no creéis?

Saludos y feliz día,

Microsoft Source Claims Xbox 720 Arriving in 2013:

http://www.tomsguide.com/us/Microsoft-Xbox-Kinect-Gaming-Console-Windows-8,news-13537.html

Next Xbox to launch in 2013 according to Microsoft:

http://www.videogamesblogger.com/2007/03/13/next-xbox-720-to-launch-in-2011-2012-according-to-microsoft.htm

Materiales del Webcast de ayer sobre Programación Paralela

Lluis Franco — Wed, 30 Nov 2011 21:34:00 GMT

Edit (07/12/2011): Ya se ha publicado el webcast, por si algun insensato lo quiere ver.
(recomiendo 'Presentación de alta fidelidad de Microsoft Office Live Meeting'):
http://www.secondnug.com/EventosDesarrollo/tabid/57/Default.aspx

:-)
Hola de nuevo,Como ya os había anunciado anteriormente, ayer realizamos un webcast con los chicos de SecondNug sobre programación paralela.

Tengo que deciros que realmente me lo pasé como un enano, tanto que de hecho ya se me han ocurrido un par de ideas para otros eventos de este tipo :-D

En estos momentos todavía no se puede descargar el evento grabado aunque me comentan que es cuestión de pocas horas, de modo que en cuanto esté disponible editaré este post y os dejaré la dirección por si algún insensato se lo quiere descargar.

Por mi parte, como ha habido bastante gente que me ha preguntado por la presentación y -sobre todo- por el código, os dejo en enlace para que lo descarguéis y juguéis con él. Y si tenéis alguna mandarme un mensaje o mejor, un tweet ;)

En la solución he incluido algunos de los ejemplos que no dió tiempo de ver, como una comparativa secuencial versus paralelo al calcular la serie de FIbonacci, o algunos ejemplos sobre las colecciones concurrentes. Particularmente os recomiendo darle un vistazo al ejemplo de uso de las BlockingCollection.

No hay copyright de ningún tipo, así que podéis hacer con él lo que queráis (aunque si os apetece mandarme un jamón, no os diré que no :-P). En fin, espero que os sirva para introduciros en este apasionante mundo de la TPL.

Si no funciona el frame de arriba también podéis acceder haciendo click en este enlace.

Un saludo y nos vemos,

Webcast: Mejora el rendimiento con Programación Paralela

Lluis Franco — Mon, 21 Nov 2011 11:19:55 GMT

El próximo 29 de Noviembre montaremos un webcast con los chicos de SecondNug sobre programación paralela.

La idea es empezar mostrando el porqué de la programación paralela: Que es? Cómo hemos llegado a esta singularidad? Y en que casos puede sernos útil -que son muchos más de los que os podéis imaginar-. Además, como vais a ver en el webcast esto cada vez va a ir a más. Y no sólo a largo plazo… pero no os quiero avanzar mucho más, mejor ya lo veréis :-D

A partir de las 19h30 empezaremos nuestro viaje por las principales características de la nueva Task Parallel Library (TPL). Comenzaremos por una breve introducción para asentar algunos conceptos (y para picaros el gusanillo), y posteriormente pasaremos a hacer demos por un tubo. Que al fin y al cabo somos developers y es lo que nos gusta!

Puedes registrarte aquí:
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032498453&Culture=es-AR

Nos vemos pronto,

PD – Mi idea era llamarlo ‘Paralelízate o muere’ pero tal vez era un poco demasiado bestia… o no? Júzgalo tu mismo :-)

[HowTo] Modificar cadena de conexión, la eterna pregunta

Lluis Franco — Thu, 20 Oct 2011 10:27:09 GMT

Si no la he leído 200 veces en los foros MSDN no la he leído ninguna :-) vayan unos ejemplos:

Es posible modificar el App.config de una aplicación C# en tiempo de ejecución?

Cómo hago para cambiar los datos de conexión en tiempo de ejecución?

Cadena de conexión Dinámica, ¿cómo debo hacer esta modificación desde un windows form en el mismo aplicativo?

Y así unas cuantas. De hecho una búsqueda me ha arrojado más de 3.000 resultados :-S

De todos modos lo que me sorprende no es tanto el alto número de veces que se hace esta pregunta, sino que cada vez que la respondo me digo a mi mismo: Haz un post y publícalo para referenciar a la gente... y siempre se me olvida :-P

Bueno, pues de hoy no pasa. Y es que curiosamente me ha llegado la misma pregunta por dos medios distintos. Uhm… casualidad? No lo creo. Sin duda es una señal divina: El MEV me está hablando y yo -pobre mortal- debo obedecer.

App.config y Machine.config

A ver, el quid de la cuestión es que la primera vez que usamos una cadena de conexión (en un DataSource, Contexto de datos, etc.) el propio Visual Studio genera en el fichero app.config una entrada con nombre para nuestra aplicación. Esta entrada es parecida a esto:

<connectionStrings>

  <clear />

  <add name="YourApp.Properties.Settings.YourAppConnectionString"

    connectionString="Data Source=.\sqlexpress;Initial Catalog=YourDataBase;Integrated Security=True"

    providerName="System.Data.SqlClient" />

</connectionStrings>

Y sirve para que si alguna vez deseamos cambiar el nombre del servidor, o la base de datos, o cualquier otro atributo, lo hagamos en un único sitio.

Antes de seguir un detalle: ¿Os habéis fijado si en vuestro app.config tenéis un clear antes de la cadena de conexión? Si no lo tenéis, os aconsejo añadirlo. Este clear lo que hace es no cargar las cadenas de conexión del fichero machine.config, que es común a todas las aplicaciones.

Y es que cuando se inicia una aplicación de .NET, se cargan las secciones comunes del machine.config y a continuación se añaden las propias de la aplicación definidas en el app.config.

Como por defecto en el machine.config tenemos esto:

<connectionStrings>

    <add name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;

    AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient"/>

</connectionStrings>

Si no usamos el tag clear, al ejecutar nuestra aplicación tendremos dos cadenas de conexión, y la primera será la del machine.config… y eso no nos gusta :-P

Así que asumiendo que ya habéis agregado el tag clear, vamos al turrón.

System.Configuration

En este ensamblado encontraremos todo lo necesario para la gestión de nuestras cadenas de configuración (y muchas cosas más).

Lo primero es agregar una referencia a este ensamblado a nuestro proyecto:

Y a continuación crearemos una clase con un par de métodos para leer y guardar las cadenas de conexión en el app.config:

public class ConnectionStringManager

    public static string GetConnectionString(string connectionStringName)

        Configuration appconfig =

            ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

        ConnectionStringSettings connStringSettings = appconfig.ConnectionStrings.ConnectionStrings[connectionStringName];

        return connStringSettings.ConnectionString;

    public static void SaveConnectionString(string connectionStringName, string connectionString)

        Configuration appconfig =

            ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

        appconfig.ConnectionStrings.ConnectionStrings[connectionStringName].ConnectionString = connectionString;

        appconfig.Save();

Básicamente, al primero se le pasa el nombre de la cadena de conexión a recuperar (por si tenemos varias) y nos devuelve la cadena de conexión. Al segundo se le pasa el nombre de la cadena de conexión y la nueva cadena de conexión modificada.

Para hacerlo un poco más sencillo y no tener que recordar el nombre de las cadenas de conexión, vamos a crear algunos métodos más en la clase. Uno que retorne la lista de nombres de las cadenas de conexión del fichero de configuración, y otro que retorne sólo el nombre de la primera (muy útil si sólo tenemos una).

public static List<string> GetConnectionStringNames()

    List<string> cns = new List<string>();

    Configuration appconfig =

        ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

    foreach (ConnectionStringSettings cn in appconfig.ConnectionStrings.ConnectionStrings)

        cns.Add(cn.Name);

    return cns;

public static string GetFirstConnectionStringName()

    return GetConnectionStringNames().FirstOrDefault();

Incluso, basándonos en este último podemos crear otro que nos devuelva la primera cadena de conexión:

public static string GetFirstConnectionString()

    return GetConnectionString(GetFirstConnectionStringName());

Let’s play!

A partir de esta clase, trabajar con las cadenas de conexión es muy sencillo. Supongamos que tenemos un formulario similar a esto:

Leer los valores de la cadena de conexión y mostrarlos es tan sencillo como esto:

private void showSavedConnectionSettings()

    SqlConnectionStringBuilder builder =

        new SqlConnectionStringBuilder(ConnectionStringManager.GetFirstConnectionString());

    connectionServerComboBox.EditValue = builder.DataSource.ToUpper();

    connectionDatabaseComboBox.EditValue = builder.InitialCatalog.ToUpper();

    if (builder.IntegratedSecurity)

        connectionAuthenticationModeRadioGroup.EditValue = 0;

        connectionUsernameTextEdit.Text = string.Empty;

        connectionPasswordTextEdit.Text = string.Empty;

    else

        connectionAuthenticationModeRadioGroup.EditValue = 1;

        connectionUsernameTextEdit.Text = builder.UserID;

        connectionPasswordTextEdit.Text = builder.Password;

Es decir, creamos un SqlConnectionStringBuilder a partir de la primera cadena de conexión del fichero de configuración y a partir de aquí, trabajamos por separado con cada una de las partes de la cadena, accediendo a las propiedades del builder (Datasource, InitialCatalog, IntegratedSecurity, etc.). De este modo las mostramos en el form, o dónde queramos...

Guardando que es gerundio

La siguiente pregunta lógica es: ¿Y para guardar sólo uno de los valores en el fichero de configuración? El típico ejemplo es modificar el nombre del servidor al instalar en el cliente final. Para ello vamos a usar también un builder, y vamos a ampliar la clase anterior con algunos métodos más. Para obtener los valores de las propiedades de la cadena de conexión y para guardarlos:

Obtener valores de propiedades de la cadena de conexión:

public static string GetSqlServerServerName()

    string cs = GetConnectionString(GetFirstConnectionStringName());

    if (cs != null)

        SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(cs);

        return builder.DataSource;

    else

        return null;

public static string GetSqlServerDatabaseName()

    string cs = GetConnectionString(GetFirstConnectionStringName());

    if (cs != null)

        SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(cs);

        return builder.InitialCatalog;

    else

        return null;

public static string GetSqlServerUserName()

    string cs = GetConnectionString(GetFirstConnectionStringName());

    if (cs != null)

        SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(cs);

        return builder.UserID;

    else

        return null;

public static string GetSqlServerPassword()

    string cs = GetConnectionString(GetFirstConnectionStringName());

    if (cs != null)

        SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(cs);

        return builder.Password;

    else

        return null;

public static bool? GetSqlServerIntegratedSecurity()

    string cs = GetConnectionString(GetFirstConnectionStringName());

    if (cs != null)

        SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(cs);

        return builder.IntegratedSecurity;

    else

        return null;

Guardar valores de propiedades en la cadena de conexión:

public static string SetConnectionStringServerName(

    string connectionString, string serverName)

    SqlConnectionStringBuilder builder =

        new SqlConnectionStringBuilder(connectionString);

    builder.DataSource = serverName;

    return builder.ConnectionString;

public static string SetConnectionStringAutenticationIntegrated(

    string connectionString)

    SqlConnectionStringBuilder builder =

        new SqlConnectionStringBuilder(connectionString);

    builder.IntegratedSecurity = true;

    return builder.ConnectionString;

public static string SetConnectionStringAutenticationSQLServer(

    string connectionString, string username, string password)

    SqlConnectionStringBuilder builder =

        new SqlConnectionStringBuilder(connectionString);

    builder.IntegratedSecurity = false;

    builder.UserID = username;

    builder.Password = password;

    return builder.ConnectionString;

public static string SetConnectionStringDatabaseName(

    string connectionString, string databaseName)

    SqlConnectionStringBuilder builder =

        new SqlConnectionStringBuilder(connectionString);

    builder.InitialCatalog = databaseName;

    return builder.ConnectionString;

Así pues, para cambiar el nombre del servidor en el app.config bastaría con:

Leer la cadena de conexión actual
Cambiar el nombre del server
Volver a guardar la cadena de conexión

string cs = ConnectionStringManager.GetFirstConnectionString();

string newConStr = ConnectionStringManager.SetConnectionStringServerName(cs, "MyNewServer");

ConnectionStringManager.SaveConnectionString(

    ConnectionStringManager.GetFirstConnectionStringName(), newConStr);

Me han quedado bastantes cosas en el tintero (recuperar los servidores SQL Server de nuestra red local, mostrar las bases de datos de un server, o crear un formulario para el usuario final). Si hay tiempo y pensáis que es un tema de interés lo veremos en futuros posts.

Nos vemos! :-D

[HowTo] Obtener fechas de principio y final de mes… y de trimestre

Lluis Franco — Wed, 05 Oct 2011 02:22:00 GMT

Vale, lo se. Es una chorrada :-)

Pero es una de esas cosas que no puedes creer que no está implementado en el framework ‘de fábrica’, y si lo está debe estar escondido porque yo no lo he encontrado. Y la cuestión es que ayer necesitaba calcular (a partir de una fecha) las fechas de inicio y final de mes, así como las fechas de inicio y final de trimestre.

Aquí está el código por si alguien se encuentra con el mismo problema:

public static class BaseTypesExtensions

    public static int GetQuarter(this DateTime d)

        return ((d.Month - 1) / 3) + 1;

    public static DateTime GetMonthFirstDate(this DateTime d)

        return new DateTime(d.Year, d.Month, 1);

    public static DateTime GetMonthLastDate(this DateTime d)

        return d.GetMonthFirstDate().AddMonths(1).AddDays(-1);

    public static DateTime GetQuarterFirstDate(this DateTime d)

        return new DateTime(d.Year, (d.GetQuarter() * 3) - 2, 1);

    public static DateTime GetQuarterLastDate(this DateTime d)

        return d.GetQuarterFirstDate().AddMonths(3).AddDays(-1);

Y lo usaríamos de este modo:

var basedate = DateTime.Today.AddYears(-1);

for (int i = 0; i < 23; i++)

    basedate = basedate.AddMonths(1);

    var logline = "Date: {0}, Month {1}-{2}, Quarter: {3}-{4}";

    Console.WriteLine(logline, basedate.ToShortDateString(),

        basedate.GetMonthFirstDate().ToShortDateString(),

        basedate.GetMonthLastDate().ToShortDateString(),

        basedate.GetQuarterFirstDate().ToShortDateString(),

        basedate.GetQuarterLastDate().ToShortDateString());

Produciendo este resultado:

Date: 05/11/2010, Month 01/11/2010-30/11/2010, Quarter: 01/10/2010-31/12/2010
Date: 05/12/2010, Month 01/12/2010-31/12/2010, Quarter: 01/10/2010-31/12/2010
Date: 05/01/2011, Month 01/01/2011-31/01/2011, Quarter: 01/01/2011-31/03/2011
Date: 05/02/2011, Month 01/02/2011-28/02/2011, Quarter: 01/01/2011-31/03/2011
Date: 05/03/2011, Month 01/03/2011-31/03/2011, Quarter: 01/01/2011-31/03/2011
Date: 05/04/2011, Month 01/04/2011-30/04/2011, Quarter: 01/04/2011-30/06/2011
Date: 05/05/2011, Month 01/05/2011-31/05/2011, Quarter: 01/04/2011-30/06/2011
Date: 05/06/2011, Month 01/06/2011-30/06/2011, Quarter: 01/04/2011-30/06/2011
Date: 05/07/2011, Month 01/07/2011-31/07/2011, Quarter: 01/07/2011-30/09/2011
Date: 05/08/2011, Month 01/08/2011-31/08/2011, Quarter: 01/07/2011-30/09/2011
Date: 05/09/2011, Month 01/09/2011-30/09/2011, Quarter: 01/07/2011-30/09/2011
Date: 05/10/2011, Month 01/10/2011-31/10/2011, Quarter: 01/10/2011-31/12/2011
Date: 05/11/2011, Month 01/11/2011-30/11/2011, Quarter: 01/10/2011-31/12/2011
Date: 05/12/2011, Month 01/12/2011-31/12/2011, Quarter: 01/10/2011-31/12/2011
Date: 05/01/2012, Month 01/01/2012-31/01/2012, Quarter: 01/01/2012-31/03/2012
Date: 05/02/2012, Month 01/02/2012-29/02/2012, Quarter: 01/01/2012-31/03/2012

Saludos,

PD – Thx al colega Omar del valle por sugerir una aproximación mucho más sencilla para GetQuarter ;-)

MVP por noveno año y cambio de categoría :-D

Lluis Franco — Sat, 01 Oct 2011 14:30:00 GMT

:-)
Hola a todos!

Un post cortito que estoy de fin de semana.

Acabo de recibir un correo (o más bien debería decir EL correo) que muchos de nosotros esperamos el 1 de Octubre:

Enhorabuena. Nos complace presentarle el programa de nombramiento MVP de Microsoft® de 2011. Este nombramiento se concede a los líderes excepcionales de la comunidad técnica que comparten de forma activa su experiencia de alta calidad y de la vida real con otras personas. Le agradecemos especialmente la contribución que ha realizado en las comunidades técnicas en el área de Visual C# a lo largo del pasado año.

El correo de la fatalidad. El correo del reconocimiento -o no- como Microsoft MVP para el próximo año. Y parece que se han vuelto a equivocar... por que alguien ha decidido que merezco estar otro año llevando ese pin tan chulo que nos regalan, y rodeado de toda esa gente tan cojonuda. Y perdonar que lo diga tan claro, pero realmente es así.

Por encima de todo (reconocimiento, beneficios, dinero y mujeres) lo mejor de este programa es la gente. Siendo MVP conoces gente que profesionalmente son unos monstruos (de buenos), y además ves cómo estos tíos dedican un % enorme de su tiempo a ayudar y colaborar desinteresadamente, haciendo crecer la comunidad. Que a su vez es la madre de todos los MVPs y de muchos otros, ya que hay gente muuuuy buena y preparada que todavía no ha tenido la oportunidad de entrar en este programa.

Además, este año si no he leído mal el correo se ha reconocido mi contribución al area de C#, en lugar de VB como hasta ahora. Supongo que es normal, ya que hace unos cuantos años que no toco nada de VB, pero de todos modos se agradece.

Muchísimas gracias a todos. De verdad :-)

Ahora permitirme copypastear unas fotos del post del año pasado... que no tengo material aquí dónde estoy de weekend :-P

Aquí tenéis algunos momentos de estos años:

Son simplemente algunos momentos escogidos al azar entre tantos buenos momentos. Encontraréis a algunos de los que ya no están, y también veréis a algunos que casi no se reconocen, jejeje… A ver que día me pongo a revisar más a fondo los cientos de archivos de fotos que tengo (sobretodo de los primeros años), seguro que aparecen auténticas ‘perlas’:-)

Un abrazo enorme a todos, los que son MVP, los que no, y en general a todos aquellos que dedican su tiempo a hacer más grande la comunidad. Todos son MVP, tengan o no tengan la distinción. Chavales, entre todos estamos contribuyendo a hacer algo grande.

</copypaste>

PD - Tengo que deciros que cada año que pasa lo llevo mejor, hoy sólo había entrado a consultar el correo 3 veces :-D

ParseTo: Un TryParse para unirlos a todos en las tinieblas

Lluis Franco — Fri, 30 Sep 2011 11:11:00 GMT

MUAHAHA!!! :-)

¿Quién no conoce los métodos Parse y TryParse?

Estos métodos son comúnmente usados para verificar si una cadena puede ser convertida a un número, fecha, etc.

El problema con éstos métodos es que pertenecen a los tipos base de .NET (int, long, decimal, DateTime), de modo que cada vez que tenemos que parsear un valor hay que utilizar un método distinto en una clase distinta. Además, en el caso de Parse si intentamos parsear un valor incorrecto (por ejemplo “123,45” a int) se produce una excepción en tiempo de ejecución, que es algo muy costoso en términos de rendimiento. Y de la sintaxis de TryParse mejor no hablar, han corrido ríos de tinta acerca de sus peculiaridades:

Ejemplos:

string s = "123,45";

int i1 = int.Parse(s); //Runtime exception (FormatException)!

int i2;

if (int.TryParse(s, out i2))

    //Parse ok! Use i2 for something...

El tema es que recientemente he tenido que hacer un uso bastante intenso de estos métodos para parsear cantidades ingentes de datos, así que he decidido buscar una implementación más cómoda y a ser posible con el mismo rendimiento que TryParse, o al menos parecido.

Primeras aproximaciones:

Lo primero que he pensado es -cómo no- en usar Generics :-) Peeeero resulta que TryParse no está declarado en ninguna interfaz que compartan los tipos base de .NET, de modo que esta aproximación no nos vale.

Mi segunda aproximación ha sido usar los TypeConverter de .NET, que ya había usado en otras ocasiones:

public static T ConvertTo<T>(this string value)

    return ConvertTo<T>(value, CultureInfo.CurrentCulture);

public static T ConvertTo<T>(this string value, CultureInfo cultureInfo)

    var typeConverter = TypeDescriptor.GetConverter(typeof(T));

    if (typeConverter.CanConvertFrom(typeof(string)))

try

            return (T)typeConverter.ConvertFromString(null, cultureInfo, value);

        catch

            return default(T);

    else

        return default(T);

Esta solución es bastante elegante ya que permite tener un sólo método extensor del tipo string y pasarle el tipo al que debe ser convertido. Además está sobrecargado para poder aceptar la cultura como argumento:

var value1 = "123456";

Console.WriteLine(value1.ConvertTo<long>());

Console.WriteLine(value1.ConvertTo<decimal>());

Console.WriteLine(value1.ConvertTo<float>());

Sin embargo esta aproximación adolece de un problema de rendimiento. Por un lado hay que crear un TypeConverter y por el otro, el único modo de saber si la conversión en factible es forzándola e interceptando la excepción en runtime. Para que os hagáis una idea, si se ejecuta 100.000 veces tarda el doble que un TryParse por cada valor correcto, lo cual es... aceptable. Pero si el valor es incorrecto y se produce una excepción tarda del orden de 100 veces más, de modo que esta opción sólo es válida para parsear datos ocasionalmente.

La definitiva: (versión 1):

Entretanto, se me ha ocurrido que se podría crear un método extensor de la clase string (al fin y al cabo nuestro propósito es parsear cadenas) al cual se le pase el método encargado de hacer el parseo de la cadena. Una paranoia, vamos… pero una vez implementado me gusta como ha quedado:

public delegate bool ParseToDelegate<T>(string value, out T result);

public delegate bool ParseToCultureDelegate<T>(string value,

    NumberStyles style, IFormatProvider provider, out T result);

public static T? ParseTo<T>(this string value,

    ParseToDelegate<T> method) where T : struct

    T result;

    if (String.IsNullOrWhiteSpace(value)) return null;

    if (method(value, out result)) return result;

    return null;

Observar que se usa un delegado a través del cual se informará el método a usar para realizar el parseo, y además, en caso de no poder realizar la conversión se devuelve un null (que a mi me basta y me sobra para saber si la conversión se ha realizado con éxito).

De este modo para usarlo, basta con:

var s = "1234,567";

Console.WriteLine(s.ParseTo<int>(int.TryParse)); //Error. Returns null

Console.WriteLine(s.ParseTo<decimal>(decimal.TryParse)); //Ok

var d = "14/05/2011 19:45";

Console.WriteLine(d.ParseTo<DateTime>(DateTime.TryParse)); //Ok

var g = Guid.NewGuid().ToString();

Console.WriteLine(g.ParseTo<Guid>(Guid.TryParse)); //Ok

Genial! :-D

El problema de la primera versión:

Cuando he querido agregar el soporte para múltiples culturas pasándole un argumento de tipo CultureInfo me encuentro con esto:

bool TryParse(string s, NumberStyles style, IFormatProvider provider, out int result);

bool TryParse(string s, IFormatProvider provider, DateTimeStyles styles, out DateTime result);

Las firmas del método TryParse de los tipos numéricos y fechas no coinciden! Y es que además tienen los argumentos en distinto orden… WTF! :-S

Pero a que gili…s se le ha ocurrido diseñarlo de este modo?

Pensemos en ello en fin de semana…

…y el lunes (si ha habido suerte) publicaremos la o las posibles soluciones. De momento, buen fin de semana! :-P

-TO BE CONTINUED-

Update (05/10/2011)

Es martes y todavía no he podido volver a ponerme con el tema :-(

De momento la solución que encontré no me agrada demasiado, y se trata de crear métodos aparte para realizar el parseo utilizando la cultura deseada.

El código quedaría de este modo:

public delegate bool ParseNumberWithCultureToDelegate<T>(string value,

    NumberStyles style, IFormatProvider provider, out T result);

public delegate bool ParseDateTimeWithCultureDelegate<T>(string value,

    IFormatProvider provider, DateTimeStyles styles, out T result);

public static T? ParseNumberWithCultureTo<T>(this string value,

    ParseNumberWithCultureToDelegate<T> method, CultureInfo cultureInfo) where T : struct

    T result;

    if (String.IsNullOrWhiteSpace(value)) return null;

    if (method(value, NumberStyles.Any,

        cultureInfo.NumberFormat, out result)) return result;

    return null;

public static T? ParseDateTimeWithCultureTo<T>(this string value,

    ParseDateTimeWithCultureDelegate<T> method, CultureInfo cultureInfo) where T : struct

    T result;

    if (String.IsNullOrWhiteSpace(value)) return null;

    if (method(value, cultureInfo, DateTimeStyles.None,

        out result)) return result;

    return null;

Y se utilizaría de este modo:

var n = "123,45";

Console.WriteLine(n.ParseTo<decimal>(decimal.TryParse)); //123.45

Console.WriteLine(n.ParseNumberWithCultureTo<decimal>(

    decimal.TryParse, new CultureInfo("en-US"))); //12345

var d = "02/05/2011 16:45";

Console.WriteLine(d.ParseTo<DateTime>(DateTime.TryParse)); //02/05/2011 16:45

Console.WriteLine(d.ParseDateTimeWithCultureTo<DateTime>(

    DateTime.TryParse, new CultureInfo("en-US"))); //05/02/2011 16:45

Funciona perfectamente y el rendimiento es entre 50 y 100 veces más rápido que el uso del TypeConverter (entre 1,1 y 1,4 veces el uso del TryParse tradicional).

En fin, a ver si saco tiempo y encuentro una solución más ‘elegante’ que ésta. Y si alguno de vosotros tiene alguna idea, será muy bien recibida ;-)

Nos vemos,

PD - Hay algunas alternativas que ni siquiera he evaluado (como el uso de Reflection) ya que mi principal requisito es ofrecer un buen rendimiento.

[HowTo] Crear una pantalla que espere la conclusión de una tarea larga (con cancelación)

Lluis Franco — Thu, 29 Sep 2011 09:52:00 GMT

En el post anterior vimos un ejemplo de cómo crear una ventana que espere la conclusión de una tarea. Si bien este ejemplo cubría sobradamente el objetivo, dejamos abierta la puerta a la posibilidad de que dicha tarea pudiese ser cancelada por petición del usuario, pulsando el botón ‘cancel’ de la ventana.

Si se hizo de este modo fue para evitar complicar en exceso el post, ya que el objetivo inicial era simplemente “mostrar una ventana mientras durase el proceso”.

Tras publicar el post y ver algunas de las reacciones en el hilo del foro de C# de MSDN (gracias Pedro por tu idea), he decidido ampliar el proyecto de ejemplo ofreciendo al usuario la posibilidad de cancelar REALMENTE la tarea, utilizando para ello un CancellationToken.

CancellationToken es una estructura nueva del .NET Framework 4.0 (así como toda la TPL en sí), y permite la cancelación de un proceso asíncrono. Es comúnmente usada cuando deseamos propagar una notificación de cancelación hacia arriba, por ejemplo, hacia el método que está siendo ejecutado como en nuestro caso.

Para ello necesitamos crear previamente un CancellationTokenSource, que es el objeto que contiene el token de cancelación y que además nos va a permitir cancelar la tarea. Posteriormente este objeto nos proporcionará el token de cancelación, que usaremos en la llamada a la tarea. Pero vamos a verlo mejor con un poco de código:

En el formulario de espera:

Aparecen algunos cambios, por ejemplo debemos modificar la firma de la propiedad ActionToExecute para que acepte un método que contenga un parámetro de tipo CancellationToken. Este parámetro será usado por el método para saber si se ha cancelado y actuar en consecuencia. De paso aprovecharemos para declarar el CancellationTokenSource.

public Action<CancellationToken> ActionToExecute { get; set; }

CancellationTokenSource cancelTokenSource = new CancellationTokenSource();

Nota importante: En el proyecto anterior, el botón ‘cancel’ no tenía código asociado. Simplemente tenía establecida la propiedad DialogResult en Cancel, de modo que al pulsarlo cerraba automáticamente la ventana y devolvía el valor Cancel a su llamador. En el proyecto actual como sí que nos interesa controlar el cierre de la ventana, es necesario establecer la propiedad DialogResult en None e interceptar su evento:

closeButton.Click += closeButton_Click;

void closeButton_Click(object sender, EventArgs e)

//

Aquí más adelante cancelaremos la tarea y devolveremos un valor DialogResult = Cancel.

Ahora vamos a centrarnos en la creación y ejecución de la tarea asíncrona:

void fSplashScreen_Shown(object sender, EventArgs e)

    titleLabel.Text = Title;

    messageLabel.Text = Message;

    pictureBox.Image = Picture;

    Task.Factory.StartNew(() =>

        ActionToExecute(cancelTokenSource.Token)).ContinueWith((t) => taskCompleted());

Como veis en realidad no hay demasiados cambios, lo único es que en la llamada a StartNew obtenemos el token de cancelación de su CancellationTokenSource, y cuando posteriormente ésta sea cancelada por el usuario, el token será propagado hasta el método que se está ejecutando, permitiendo su cancelación.

Hablando del método, que modificaciones hay que realizar?

El método original era este:

private void DoSomeHardWork()

    for (int i = 0; i < 50; i++)

        Console.WriteLine(i);

        Thread.Sleep(100);

Y el nuevo quedaría así:

private void DoSomeHardWorkWithCancellation(CancellationToken cancelToken)

try

        for (int i = 0; i < 50; i++)

            cancelToken.ThrowIfCancellationRequested();

            Console.WriteLine(i);

            Thread.Sleep(100);

    catch (Exception ex)

        MessageBox.Show(ex.Message, Application.ProductName,

            MessageBoxButtons.OK, MessageBoxIcon.Exclamation);

Como decíamos antes, este método recibe un parámetro de tipo CancellationToken y lo único que hay que hacer es lanzar una excepción en caso que haya sigo solicitada una cancelación (de ahí que se envuelva el código dentro de un bloque try-catch).

Nada más. Una sólo línea y el pertinente bloque de intercepción de errores… y voilá! No os parece bonito y elegante? :-)

Por cierto, en caso que no se desee lanzar una excepción es posible que os interese preguntar por el valor de la propiedad IsCancellationRequested y elegir vosotros mismos la acción más apropiada.

Volvamos al formulario de espera y completemos el código que falta. Primeramente el código del botón ‘cancel’, encargado de cancelar realmente la tarea:

void closeButton_Click(object sender, EventArgs e)

    DialogResult = DialogResult.Cancel;

    cancelTokenSource.Cancel();

    releaseCancellationTokenSource();

private void releaseCancellationTokenSource()

    if (cancelTokenSource != null)

        cancelTokenSource.Dispose();

        cancelTokenSource = null;

Y por último, agregar una línea para liberar también el token al finalizar con éxito la tarea:

private void taskCompleted()

    if (InvokeRequired)

        this.Invoke((MethodInvoker)(() =>

            Close();

            DialogResult = DialogResult.OK;

        }));

    releaseCancellationTokenSource();

Y con esto y un bizcocho, hemos terminado! Espero que os haya gustado :-D

Muchas gracias de nuevo a Pedro Hurtado y a toda la gente del foro de C# en MSDN :-)

Os dejo también el mini proyecto de ejemplo por si queréis jugar un rato:

Nos vemos,

[HowTo] Crear una pantalla que espere la conclusión de una tarea larga

Lluis Franco — Wed, 28 Sep 2011 13:49:00 GMT

Nota: Otro post en respuesta a una pregunta bastante habitual en los foros MSDN: “Mi frmPrincipal ejecuta una función (no tengo el tiempo preciso) y mientras realiza esto quiero que aparezca una ventana … que impida el acceso al frmPrincipal y una vez que se termine de ejecutar la función, desaparezca frmMensaje.”

La verdad es que hay un montón de posibles soluciones. Desde el uso del componente BackgroundWorker (la opción más sencilla pero la que menos me gusta :-P) hasta los futuros async y await que vendrán con C# 5, pasando por los clásicos threads de toda la vida o las tareas que se introdujeron con la TPL en Visual Studio 2010.

Para este ejemplo vamos a utilizar ésta última aproximación, ya que de las otras hay millones de ejemplos de todos los tipos y colores. Además, puede servir como -sencillo- ejercicio de uso de la clase Task, para que quién no la conozca vaya introduciéndose en el maravilloso mundo de la programación paralela.

Primeramente vamos a crear un formulario con un título, un mensaje y una barra de progreso de tipo marquesina, ya que como dice el enunciado “no se conoce de antemano la duración de la tarea a ejecutar”. Y para comprobar que la tarea se ejecuta en segundo plano (en realidad en paralelo si hay más de un core en el procesador) también añadiremos un botón para poder cerrar la ventana.

Aviso: Este botón únicamente sirve para cerrar la ventana y retornar a la ventana principal. Realmente no va a cancelar la tarea, para eso se requeriría un CancellationToken, y no quiero complicar tanto el ejemplo... Aunque tal vez sea buena idea verlo en otro post, más adelante.

El punto de partida será la ventana principal. En mi caso y para no complicarme la vida he creado un formulario muy sencillo con un sólo botón, y que contiene un método que se supone que va a tardar un cierto tiempo en ejecutarse. Iba a poner ‘un huevo’ pero prefiero no hacerlo para no herir susceptibilidades :-)

El formulario principal:

El método que tarda… mucho:

private void DoSomeHardWork()

    for (int i = 0; i < 50; i++)

        Console.WriteLine(i);

        Thread.Sleep(100);

El formulario que espera a que la tarea termine:

Una vez diseñada el formulario de espera, le agregaremos algunas propiedades como el título, mensaje, y sobre todo el método que deseamos ejecutar en forma de Action:

public string Title { get; set; }

public string Message { get; set; }

public Image Picture { get; set; }

public Action ActionToExecute { get; set; }

Una vez creadas estas propiedades, podemos volver al formulario principal y hacer la llamada a la ventana de espera, pasándole los valores oportunos:

private void button1_Click(object sender, EventArgs e)

    using (fWaitForTaskScreen fwait = new fWaitForTaskScreen())

        fwait.Title = "Executing a looooong task...";

        fwait.Message = "This form will close when the task completes its work.\nJust wait a few seconds... :-)";

        fwait.Picture = Properties.Resources.LogoWeb30_small;

        fwait.ActionToExecute = DoSomeHardWork;

        if (fwait.ShowDialog() == DialogResult.OK)

            MessageBox.Show("OK");

        else

            MessageBox.Show("Cancel or error");

Lo único importante aquí es la forma en que le pasamos el método que debe ejecutar. Estamos usando una propiedad de tipo Action, que representa un método con un parámetro que no retorna un valor. De modo, que -ya os aviso- sirve para ejecutar cualquier método que no devuelva un valor. En caso que queramos devolver un valor podríamos utilizar una propiedad pública, o mejor un delegado Func<T, TResult>. Pero como os decía antes, prefiero no complicar el ejemplo.

El código es muy sencillo, como podéis ver. Crea el formulario de espera, le pasa los valores (incluyendo el método a ejecutar) y examinamos el valor de DialogResult para saber si ha terminado con éxito la tarea o no, o se ha cancelado por el usuario.

Y a todo esto ¿cómo se ejecuta el método de forma asíncrona?

Pues aquí está la gracia de este ejercicio. Ya veréis lo sencillo que resulta, sobre todo para aquellos acostumbrados a trabajar ‘a pelo’ con threads:

void fSplashScreen_Shown(object sender, EventArgs e)

    titleLabel.Text = Title;

    messageLabel.Text = Message;

    pictureBox.Image = Picture;

    Task.Factory.StartNew(ActionToExecute).ContinueWith((t) => taskCompleted());

private void taskCompleted()

    if (InvokeRequired)

        this.Invoke((MethodInvoker)(() =>

            Close();

            DialogResult = DialogResult.OK;

        }));

Vayamos por partes. El primer bloque es realmente la parte importante. De hecho, la última línea es la que se encarga de todo. Crea y ejecuta una tarea asíncrona que apunte al método que le hemos pasado al formulario, y no sólo hace eso, si no que además le decimos que cuando termine ejecute una segunda tarea ‘taskCoompleted’. A esto se le llama ‘encadenamiento’ de tareas, y es muy útil cuando una tarea depende de otra.

Y que hace la segunda tarea? Apenas nada. Cierra el formulario y devuelve el valor OK para que la ventana principal sepa que todo ha terminado bien. Lo único que sucede es que -al igual que cuando usamos threads- en .NET no se puede modificar un control fuera del thread que lo ha creado, eso es, el thread principal. Y nuestras tareas se están ejecutando en otros threads creados de forma transparente por la tarea. De modo que para poder llamar al método Close o modificar la propiedad DialogResult debemos hacerlo mediante Control.Invoke, y por ese motivo el código es un poco extraño a primera vista.

Os dejo el mini proyecto de ejemplo por si queréis jugar un rato:

Nos vemos,

Funciones escalares en TSQL, JOINS, CROSS APPLY, y la madre que parió al topo.

Lluis Franco — Mon, 26 Sep 2011 14:52:00 GMT

Nota: Si eres desarrollador de TSQL puedes saltarte la introducción e ir directamente al tajo ;-)

Introducción

Una de las cosas que más me gustan de SQL server -partiendo de la base de que uno es developer- son las funciones. Existen funciones de dos tipos: Aquellas que devuelven un valor escalar (Scalar-valued) y aquellas que devuelven un valor de tipo tabla (Table-valued), es decir, un conjunto de registros.

Aunque las funciones aparecieron en SQL Server 2000, no fue hasta la aparición de SQL Server 2005 cuando empecé a usarlas de forma más o menos intensa. A partir de entonces decidí que casi todo el código que tenía en TSQL en realidad podía estar en funciones, no en procedimientos almacenados como hasta entonces. Y cuando digo casi todo me refiero a que aquí hay que diferenciar el código que principalmente PROCESA datos para devolver un resultado (FUNCIONES), del código del que meramente realiza ACCIONES (inserts, updates, deletes) sobre los datos (SP).

En mi caso particular, resultó que más de un 85% del código TSQL era candidato a ser encapsulado en funciones, así que con los años he ido creando una capa de funciones escalares y de tipo tabla para acceder a los datos de varias bases de datos. Y es que desde el punto de vista de un desarrollador resulta muy tentador poder llevar la encapsulación, uno de nuestros principios favoritos de la orientación a objetos al mundo de las base de datos: Por ejemplo, crear una función de tipo tabla en base a unos parámetros de entrada y poder tratar el resultado como una tabla o vista, haciendo joins, wheres y orders sobre ella es brutal. Y crear una función escalar que realice una serie de complejas acciones a partir de los parámetros que recibe y devuelva un resultado que va a ser usado en multitud de ocasiones no tiene precio.

CREATE function [dbo].[GetDescriptionScalar](@oId int)

RETURNS VARCHAR(max)

AS

BEGIN

    DECLARE @res VARCHAR(max)

    SET @res=

        (SELECT

        [From] + ': ' + [Subject] +

        CASE WHEN HasAttachment = 1 THEN

        ' (with data)'

        ELSE

''

END

        FROM [dbo].[ServerSideGridTest]

        WHERE OID = @oId)

    RETURN @res

END

Ejemplo de función escalar: A partir de un identificador componemos una descripción basada en algunos campos de la tabla.

Rendimiento versus un buen diseño

Sin embargo, estamos haciendo bien las cosas? En ocasiones no nos damos cuenta de que podemos estar pagando un precio muy alto (rendimiento) a cambio de tener un buen diseño que facilita el mantenimiento. O lo que es peor, a veces damos por asumida una pérdida de rendimiento a sabiendas de que ganamos en diseño y reutilización de código. Y esto -en ocasiones- se lleva al extremo con el uso de funciones escalares.

Nadie duda de que la anterior función es perfectamente válida, y aunque sea muy simple ilustra perfectamente los beneficios de la encapsulación que permite TSQL. Ahora bien ¿que ocurre cuando lanzamos una consulta como esta?

SELECT t.*, dbo.GetDescriptionScalar(t.oid)

FROM [ServerModeGridProjects].[dbo].[ServerSideGridTest] t

Supongo que ya os imagináis que es una animalada, no? Estamos ejecutando la función por cada fila de la tabla (en mi caso de ejemplo 100.000 filas), de modo que por muy optimizada que esté la función, el rendimiento es bastante penoso, y me recuerda más a un cursor (otro de los demonios particulares de SQL Server) que a otra cosa. Sobre todo si lo comparamos con la misma instrucción en una sola sentencia SQL, ya que el resultado es prácticamente inmediato.

Demos una ojeada al plan de ejecución:

1) Usando la función escalar

SELECT t.*, dbo.GetDescriptionScalar(t.oid)

FROM [ServerModeGridProjects].[dbo].[ServerSideGridTest] t

2) Usando una sola sentencia SQL

SELECT t.*, [From] + ': ' + [Subject] +

        CASE WHEN HasAttachment = 1 THEN

        ' (with data)'

        ELSE

''

        END AS [Description]

FROM [ServerModeGridProjects].[dbo].[ServerSideGridTest] t

A simple vista parecen idénticos, sin embargo en el primer caso la consulta tarda 01:04 (si, ¡más de un minuto!), y en el segundo apenas tres segundos… WTF?

Vamos a ver que nos dicen las estadísticas:

1) Usando la función escalar

2) Usando una sola sentencia SQL

Aquí ya podemos observar alguna diferencia no sea con demasiado detalle, sobretodo en las tres últimas filas. Con todo, todavía no hemos visto realmente qué es lo que sucede DENTRO del servidor cuando lanzamos ambas consultas. Vamos a bajar un poco más a nivel de detalle usando el SQL Profiler. Concretamente nos interesa capturar dos eventos, SQL:BatchCompleted y SP:Completed, además de algunas columnas cómo la CPU, Duration y sobretodo Reads y Writes.

1) Usando la función escalar

Más claro agua. Realmente ahora si que estamos viendo cómo la función escalar se ejecuta por cada fila, provocando lo que en inglés se llama RBAR (row-by-agonizing-row). Pero lo más preocupante es el número total de lecturas y escrituras. Fijaros en la imagen siguiente y podréis comprobar que la proporción de lecturas es de 9.603.581 a 2.243. Casi 4.300 veces más!

2) Usando una sola sentencia SQL

Bárbaro! No hay comparación posible… Entonces ¿creéis que en este caso compensa crear una función escalar? En absoluto.

¿Significa esto que no hay que usar funciones escalares en ningún caso? No, pero significa que debemos evaluar con mucho cariño dónde hay que usarlas.

¿Y entonces, dónde no hay que usar funciones escalares?

Sobretodo en valores de columna en un SELECT, como era el caso anterior, pero tampoco en la clausula WHERE ya que también provocará que se ejecute por cada fila, a fin de evaluar si cumple o no la condición. Tampoco ORDER BY… Entonces que nos queda? En valores predeterminados de columna? Bueno, tal vez, si no nos vamos a dedicar a realizar INSERTS masivos :-S

Tal vez alguien que sepa más que yo de SQL pueda aclararnos dónde usar funciones escalares, pero por el momento voy a descartar su uso. Máxime cuando existen alternativas :-)

Funciones de tabla

Bien, todo esto es muy bonito pero en la vida real NECESITAMOS USAR FUNCIONES. Esta abstracción es primordial en muchos casos, sobre todo cuándo la lógica de negocio es compleja. Y que conste que no pretendo iniciar la eterna discusión acerca de si es recomendable o no implementar ésta en la capa de persistencia de datos o en otra capa de la aplicación. De hecho, siempre he defendido que contra menos código exista en la BD mejor :-P

Sin embargo hay ocasiones en las que el aumento de rendimiento no se puede obviar. En un proyecto en el que estoy trabajando actualmente, hay tal cantidad de datos y se realizar unos procesos tan bestias que uno de los algoritmos de cálculo -optimizado- tardaba cerca de un minuto. Moviendo esta algoritmo de la aplicación a una serie de funciones hemos conseguido que sea casi instantáneo.

Vale, y cómo hemos hecho esto? Usando funciones de tabla.

Existen dos tipos de funciones de tabla, pero ahora las trataremos por un igual, ya que en ambos casos lo que se devuelve ese un conjunto de filas y columnas. De este modo sería perfectamente transformar la anterior función escalar en esto:

CREATE FUNCTION [dbo].[GetDescriptionTable](@oId int)

RETURNS TABLE

AS

RETURN

SELECT

    [From] + ': ' + [Subject] +

    CASE WHEN HasAttachment = 1 THEN

    ' (with data)'

    ELSE

''

    END as Description

FROM

    [dbo].[ServerSideGridTest]

WHERE

    OID = @oId

Observar que aunque se trata de una función de tipo tabla en realidad estamos devolviendo un sólo campo y un sólo registro. En cualquier caso esto no es para nada importante, y de hecho la verdadera potencia del uso de funciones de tipo tabla radica en devolver conjuntos de registros, y cómo no, realizar sobre éstos operaciones de tipo JOIN, WHERE, etc.

¿No sería genial poder hacer un JOIN de una tabla con el retorno de una función de tipo tabla? Pues es posible hacerlo… salvo en el caso que la función espere un parámetro que referencie la fila. Por ejemplo, el siguiente código no es válido (supongamos que la función anterior de tipo tabla también devuelve el Id):

SELECT

    t.*, dt.[Description] AS [Description]

FROM

    [ServerModeGridProjects].[dbo].[ServerSideGridTest] t

INNER JOIN GetDescriptionTable(t.oid) dt

ON t.OId = dt.OId

Se producirá un error, ya que SQL Server no es capaz de resolver GetDescriptionTable(t.oid).

CROSS APPLY al rescate!

Aquí entra este operador (bueno, en realidad son dos) que permite combinar los valores del lado izquierdo con los del lado derecho, creando el conjunto de resultados deseado. Utilizarlo es tan sencillo como esto:

SELECT t.*, dt.[Description] AS [Description]

FROM [ServerModeGridProjects].[dbo].[ServerSideGridTest] t

CROSS APPLY GetDescriptionTable(t.oid) dt

Sencillo y hermoso. Pero, que tal anda de rendimiento?

Pues muy bien, la verdad. Tarda exactamente tres segundos. Lo mismo que el caso anterior en el que teníamos una sola sentencia SQL. Es más, si mostramos las estadísticas vemos que se comporta de forma muy parecida:

Se puede apreciar un ligero aumento de las lecturas, pero en realidad no es nada significativo en términos de rendimiento, ya que la duración es exactamente la misma.

Conclusión

Las funciones escalares pueden suponer un problema serio de performance. Sobre todo cuando no se tiene en mente cómo funcionan. Una alternativa a tener en cuenta es utilizar funciones de tipo tabla en combinación con CROSS APPLY, ya que proporcionan un buen diseño a la vez el rendimiento no se ve penalizado en absoluto.

BTW creo que voy a tener que replantearme esto de escribir… cada vez me salen posts más ‘tochos’.

Enhorabuena si has llegado hasta aquí ;-)

Nos leemos,

Usando SQL Server Table-Valued Parameters en C# (mediante un Custom Iterator)

Lluis Franco — Mon, 12 Sep 2011 14:42:00 GMT

Una de las características más esperadas de SQL Server 2008 son los parámetros de tipo tabla en procedimientos almacenados y funciones de SQL SERVER.

Estos Table-Valued Parameter (TVP en adelante ) permiten definir un tipo de datos estructurado (al fin!) que puede ser pasado como parámetro a un PROCEDURE o a una FUNCTION, mejorando sustancialmente el manejo de datos de tipo tabla, ya que anteriormente dependíamos de tablas temporales o variables de tipo tabla, pero ambas tenían varios inconvenientes. Las primeras por ejemplo sólo eran accesibles en la conexión actual, mientras que las segundas ni siquiera podían ser accedidas desde otros elementos procedimientos o funciones.

SQL Server 2008 y TVP al rescate!

Mediante los TVP podemos definir un tipo fuertemente tipado en el servidor (valga la rebuznancia :-P), y usarlo para definir los parámetros de nuestros procedimientos o funciones. De este modo estamos portando una de las cosas que más me gustan de la OOP a TSQL, que dicho sea de paso, falta le hacía. Además, nos permite solventar algo que desde tiempo ha llevado de cabeza a muchos desarrolladores: El poder enviar en un sólo viaje al servidor varias filas.

Vamos a ver. Que levante la mano quién no se ha dado cabezazos para tratar de mandar varios valores a un procedimiento o función desde una aplicación cliente?

A lo largo de los años he visto soluciones más o menos ingeniosas, desde pasar un ‘chorizo’ de 4000 caracteres separados por comas y usarlo con SQL dinámico o volcarlo en una tabla temporal para hacer un JOIN, hasta usar XML para el paso de valores, pasando por tablas temporales globales y otras ‘perlas’. En todos los casos las soluciones distaban mucho de ser perfectas y comportaban serios problemas de rendimiento al tener que implementar lógica en ambos extremos para empaquetar y desempaquetar los valores.

Aquí los TVP nos vienen a echar un cable, ya que permiten definir un tipo de registro que luego pasaremos a SQL Server, aunque la gracias de todo está en -como veremos un poco más adelante- crearse un custom iterator en c#.

Manos a la obra: Coding

Un escenario típico (y que vamos a usar como ejemplo) es el de tener una aplicación cliente que permite seleccionar un subconjunto de datos, por ejemplo bancos. Y posteriormente, envía ésta selección de elementos a un procedimiento o función que realice *algo* con éstos datos, como por ejemplo mostrar un listado por pantalla, report, etc.

La parte del servidor es la más sencilla, supongamos que partimos de un par de tablas de bancos y oficinas:

Basta con crear un tipo de datos de tipo tabla (con un sólo campo para simplificar):

CREATE TYPE [dbo].[MultiSelectionList] AS TABLE(

    [Id] [int] NULL

GO

A continuación usamos este tipo en las funciones o procedimientos almacenados para recibir los valores como una tabla de elementos de este tipo :

CREATE FUNCTION [dbo].[GetBanksOffices](@SELECTION AS MultiSelectionList READONLY)

RETURNS TABLE

AS

RETURN

  SELECT * FROM [system].[BankOffices] BO

  INNER JOIN @SELECTION S

  ON BO.BankId = S.Id

Observar el uso de READONLY, ya que es imperativo que la lista de valores no se pueda modificar desde el cuerpo de la rutina TSQL. Por otro lado, la lista de valores se trata a todos los efectos como una tabla temporal, o variable de tipo tabla. Así pues podemos realizar un JOIN sobre ella sin más, y aquí radica la belleza de los TVP, nos permiten un código mucho más limpio. Y como todos sabemos, contra más limpio es un código, menos propenso a errores resulta.

La parte del cliente es un poco más compleja, ya que supongo que la mayoría os estaréis preguntando “vale ¿pero cómo demonios se le pasa un parámetro de este tipo desde .NET?”, y con razón. Este tipo es un tipo de datos personalizado que *sólo* conoce nuestro servidor. Sin embargo en .NET podemos crearnos el equivalente a este tipo mediante una clase, y luego mediante una lista genérica pasárselo a la función mediante un SqlParameter… o lo sería si existiese un tipo de parámetro adaptado a las colecciones genéricas, cosa que no es así.

Entonces que hacemos? Pues lo primero empezar por lo básico: Hay que crear una clase equivalente al tipo de datos de SQL SERVER:

public class MultiSelectionItem

    public int Id { get; set; }

    public MultiSelectionItem(int id)

        Id = id;

Ya tenemos lo básico para empezar. Ahora a ver cómo podemos conectar nuestros objetos de negocio con los TVP de SQL SERVER:

El mecanismo que nos proporciona ADO.NET para acceder a procedimientos o funciones son los archiconocidos SqlCommand y SqlParameter, los cuales he usado infinidad de veces. Sin embargo, hasta hoy no conocía la existencia de uno de los valores de la enumeración SqlDbType: El valor Structured. Cuando usamos este valor para definir el tipo del parámetro de SQL Server, en realidad estamos especificando que vamos a usar un TVP. Esto parece solventar parte del problema, ahora sólo nos falta ver como convertir una colección de objetos MultiSelectionItem y ‘convertirla’ a un objeto que podamos pasarle al parámetro.

Ahora demos un vistazo a la clase SqlDataRecord, que representa una fila de datos junto con sus metadatos, y está especialmente indicada para su uso en conjunción con SqlCommand y SqlDataReader, para enviar y recibir información de procedimientos y funciones utilicen TVP.

Es muy posible que estéis pensando en usar esta clase como ‘puente’ entre ambos mundos, y la verdad es que SI SE PUEDE. Y además, creo que de forma muy elegante.

Custom iterators en C#

Un iterador es un método que realiza una iteración personalizada sobre una colección a través de la palabra reservada yield. La instrucción yield return provoca que un elemento en la secuencia de origen sea devuelto de inmediato al método llamador que llama antes de que el siguiente elemento de la secuencia de origen sea procesado. En otras palabras, nos permite hacer algo tan bonito como esto:

public class MultiSelectionCollection : List<MultiSelectionItem>, IEnumerable<SqlDataRecord>

    IEnumerator<SqlDataRecord> IEnumerable<SqlDataRecord>.GetEnumerator()

        var sqlDataRecord = new SqlDataRecord(new SqlMetaData("Id", SqlDbType.Int));

        foreach (MultiSelectionItem multiSelectionItem in this)

            sqlDataRecord.SetInt32(0, multiSelectionItem.Id);

            yield return sqlDataRecord;

De verdad que a veces no me imagino la vida antes de la aparición de Generics :-P

Poniéndolo todo junto

Recapitulemos. Por un lado tenemos el TVP que hemos creado en SQL SERVER, y que posteriormente hemos usado en una función de usuario de tipo tabla. A continuación hemos creado una clase equivalente en la aplicación cliente, y finalmente hemos creado una clase que hereda de una lista genérica de nuestro tipo equivalente, y que implementa la interfaz IEnumerable, para así poder crear un iterador personalizado que ‘convierta’ la lista de elementos MultiSelectionItem en algo inteligible para SQL Server, en este caso una secuencia de elementos SqlDataRecord.

Y ahora que? Ahora, sólo queda hacer la llamada a la función. Es decir, crear la colección de valores a pasar a SQL SERVER, hacer la llamada y recoger los datos de vuelta:

public static List<BankOffice> GetBanksOffices(MultiSelectionCollection selectedbanks)

    var officebanks = new List<BankOffice>();

    using (SqlConnection sqlcon = new SqlConnection(

        ConnectionStringManager.GetFirstConnectionString()))

try

            sqlcon.Open();

            const string sql = "SELECT * FROM dbo.GetBanksOffices(@SELECTION)";

            using (SqlCommand sqlcmd = new SqlCommand(sql, sqlcon))

                SqlParameter param = new SqlParameter("@SELECTION", SqlDbType.Structured);

                param.TypeName = "MultiSelectionList";

                param.Value = selectedbanks;

                sqlcmd.Parameters.Add(param);

                var result = sqlcmd.ExecuteReader(CommandBehavior.CloseConnection);

                while (result.Read())

                    BankOffice newoffice = new BankOffice

                        BankOfficeId = int.Parse(result[0].ToString()),

                        ShowOrder = int.Parse(result[1].ToString()),

                        BankId = int.Parse(result[2].ToString()),

                        OfficeId = int.Parse(result[3].ToString()),

                        Name = result[4].ToString()

};

                    officebanks.Add(newoffice);

        catch (Exception)

            throw;

    return officebanks;

Un par de cosas importantes: Aunque parece que estamos haciendo lo de siempre, fijaros en que el tipo de datos del parámetro de SQL SERVER es SqlDbType.Structured, y además hay que indicar el nombre del tipo de datos de SQL SERVER mediante la propiedad TypeName. Esto es más importante de lo que parece, ya que el nombre del tipo de datos de SQL SERVER no tiene por que coincidir con el nombre que hemos dado a nuestra clase en la aplicación cliente.

Y para probar la llamada, basta con crear una colección con los valores que deseamos pasar a la función:

var selectedbanks = new MultiSelectionCollection();

selectedbanks.Add(new MultiSelectionItem(1));

selectedbanks.Add(new MultiSelectionItem(3));

var result = TVPExtensions.GetBanksOffices(selectedbanks);

result.ForEach(p => Console.WriteLine(string.Format("{0}, {1}", p.BankId, p.Name)));

Y tachán!!! Ya hemos visto cómo pasar listas de valores a procedimientos y funciones de SQL mediante TVP.

Nos leemos ;-)

Editar documentos almacenados como array de bits en SQL Server [FileStream] (3/n)

Lluis Franco — Fri, 19 Aug 2011 10:52:32 GMT

Es viernes, así que intentaré terminar la serie. Espero que no me quede un post muy ‘tocho’ :-P

Después de abrir boca con los dos posts anteriores, en los que hemos mostrado cómo crear una tabla con almacenamiento FILESTREAM, y posrteriormente cómo almacenar en ella documentos en forma de información binaria, hoy vamos a terminar la serie viendo cómo poder visualizar esta información mediante su aplicación asociada (Word, Excel, Acrobar Reader, etc.) y cómo no, editarla para guardar los cambios otra vez en la base de datos.

Mis disculpas :-)

Antes de continuar os quiero decir que mi intención original era encontrar una solución más elegante, pero como no he sido capaz de encontrarla (y por lo que he visto en Internet, no he sido el único) os dejo una solución que no es tan elegante, pero al menos funciona.

Que cual era mi intención original? Pues me hubiese gustado poder abrir directamente la información binaria en -por ejemplo- Word. Creía que lo podría conseguir obteniendo un handle y pasándoselo a la aplicación asociada… pero los handles obtenidos mediante OpenSqlFilestream son locales al proceso :-(

Dicho de otro modo, podemos acceder al fichero, leerlo, editarlo, pero sólo si lo hace nuestra aplicación. Si el fichero debe ser controlado a través de otra aplicación no podemos pasarle el handle. Así que esta opción no sirve.

Otra opción que contemplé (inspirado en mi querido y odiado SharePoint) fue crear un manejador HTTP con ASP.NET, ya que algunas aplicaciones son capaces de trabajar con documentos abiertos a través de una URL. Sin embargo, sólo conseguí hacerlo funcionar con documentos de Office (y no en el 100% de los casos).

La solución. Mi solución (seguro que hay más)

Así pues tuve que recurrir a la opción que pretendía evitar a toda costa, que no es otra que: Leer la información binaria, crear un fichero temporal en la estación cliente y abrirlo con la aplicación asociada. Que tiene de malo esta solución? Pues que para visualizar documentos funciona muy bien, pero en realidad estamos mostrando –y editando- una copia del documento, de modo que para revertir los cambios que hace el usuario a la base de datos tenemos un problema. Un problemón.

Después de darle algunas vueltas y comentarlo con más gente (gracias Pablo Gavela!) al final me decanté por utilizar la clase Process. Si, la misma clase process que hemos usado miles de veces para ejecutar aplicaciones o mostrar documentos. La clase process puede lanzar un proceso de forma síncrona o asíncrona.

La primera la deseché en seguida porque creo que usa algo que los viejos programadores del API de Win32 aprendimos a temer: WaitForExit (que llama a WaitForSingleObject). Además, la aplicación deja de responder hasta que se termina el proceso lanzado, con lo que ni siquiera repinta la ventana.

La segunda permite lanzar un proceso y monitorizar el momento en que se cierra mediante el evento ‘Exited’. De modo que podemos saber el momento en que se cierra la aplicación asociada, verificar si se ha cambiado el documento y en caso afirmativo volver a guardarlo en la base de datos.

Nota importante: Si queremos que se dispare el evento ‘Exited’ hay que activar la propiedad ‘EnableRaisingEvents’.

Un poco rocambolesco? Tal vez. Así que si alguien encuentra una solución más sencilla que lo haga público. Por favor :-)

Al fin! El maldito código

Mi propuesta es crear una clase derivada de Process con la información adicional que necesitamos para el manejo de los datos binarios. En este caso particular necesito que el proceso ‘conozca’ el identificador del registro (FileId Guid), el nombre original del documento (o al menos su extensión), y evidentemente los propios datos binarios.

La idea es pasarle estos datos ‘extra’ en el constructor, y posteriormente llamar a un método que se encargue de crear el fichero temporal y obtener la fecha de la última escritura. Posteriormente ‘escucharemos’ el evento ‘Exited’ y cuando se dispare verificaremos si hay cambios (comparando la fecha de última escritura con la anterior) y si los hay, guardaremos los cambios en la base de datos a través del FileId que hemos pasado enteriormente al proceso.

La clase ProcessController

public class ProcessController : Process

    DateTime originalLastWriteTime;

    Byte[] document = null;

    string tempfileName = string.Empty;

    public string TempFileName

get

            return tempfileName;

    Guid fileId;

    public Guid FileId

get

            return fileId;

    public ProcessController(Byte[] documentBytes, Guid docId, string originalfilename)

        : base()

        tempfileName = Path.GetTempFileName().Replace("tmp", getExtension(originalfilename));

        document = documentBytes;

        fileId = docId;

        this.StartInfo.FileName = tempfileName;

    public void EditInAssociatedApplication()

        if (tempfileName == null) return;

        if (File.Exists(tempfileName)) File.Delete(tempfileName);

        File.WriteAllBytes(tempfileName, document);

        originalLastWriteTime = File.GetLastWriteTime(tempfileName);

        this.EnableRaisingEvents = true;

        this.Start();

    public bool HasChanged()

        if (tempfileName == null) return false;

        var modifiedtime = File.GetLastWriteTime(tempfileName);

        return (modifiedtime != originalLastWriteTime);

    private string getExtension(string filename)

        var parts = filename.Split('.');

        if (parts.Length > 0)

            return parts[parts.Length - 1];

        else

            return string.Empty;

Para usar esta clase en nuestra aplicación lo mejor es tener una lista con los procesos que vamos abriendo, y por cada uno de ellos escuchar su evento ‘Exited’. De este modo cada vez que abrimos un proceso nuevo lo agregamos a la lista, y cada vez que se cierra un proceso, comprobamos si hay cambios y lo volcamos a la base de datos. Un ejemplo:

List<ProcessController> Processes = new List<ProcessController>();

private void editDocument(Guid docId)

    var filestreamDoc = context.FileStreamDocuments.FirstOrDefault(

        p => p.FileId == docId);

    if (filestreamDoc == null) return;

    ProcessController process = new ProcessController(

        filestreamDoc.Document.ToArray(),

        filestreamDoc.FileId, filestreamDoc.OriginalPath);

    process.Exited += process_Exited;

    process.EditInAssociatedApplication();

    Processes.Add(process);

void process_Exited(object sender, EventArgs e)

    ProcessController process = sender as ProcessController;

    if (process == null) return;

    if (process.HasChanged())

        saveDocument(process.FileId, process.TempFileName);

private void saveDocument(Guid docId, string filename)

    var filestreamDoc = context.FileStreamDocuments.FirstOrDefault(

        p => p.FileId == docId);

    if (filestreamDoc == null) return;

    if (File.Exists(filename))

        filestreamDoc.Document = File.ReadAllBytes(filename);

        context.SubmitChanges();

No quiero alargar más el post, así que os dejo algo como ejercicio por si alguien se anima:

Cada vez que se cierra un proceso deberíamos eliminarlo de la lista.
Si el usuario cierra la aplicación y existen procesos abiertos, deberíamos avisarlo.

Ala, ya doy por acabada la serie. Y justo a tiempo. Nos leemos :-)

Editar documentos almacenados como array de bits en SQL Server [FileStream] (2/n)

Lluis Franco — Thu, 18 Aug 2011 11:41:00 GMT

En el anterior post de la serie os comentaba: “En los próximos posts veremos dónde se almacenan REALMENTE estos ficheros, cómo visualizarlos, y lo más importante de todo, cómo editarlos y guardarlos otra vez en la base de datos de forma transparente para el usuario.”

Dicho y hecho. Vamos a dar una ojeada al servidor SQL para ver dónde se almacenan estos ficheros. Recordar que al crear la base de datos debemos especificar un FILEGROUP explícitamente para el almacenamiento FILESTREAM:

CREATE DATABASE Archive

ON

PRIMARY ( NAME = Arch1,

    FILENAME = 'c:\data\archdat1.mdf'),

FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM( NAME = Arch3,

    FILENAME = 'c:\data\filestream1')

LOG ON  ( NAME = Archlog1,

    FILENAME = 'c:\data\archlog1.ldf')

GO

El ejemplo anterior crea una estructura de carpetas y ficheros en la ubicación especificada del servidor SQL. Observar que no tiene porque ser la misma que los ficheros MDF y LDF, es más, para escenarios de alto rendimiento no os lo aconsejo precisamente.

Si damos una vistazo a esa estructura veremos que por defecto se crea un fichero filestream.hdr y una carpeta $FSLOG. El primero contiene los metadatos para el contenedor de los datos y el seguindo es el equivalente del log de transacciones de una base de datos. Pura magia!

En nuestro caso, aparece además una carpeta por cada entidad o tabla que contiene campos binarios con almacenamiento FILESTREAM. Como me he decicado a insertar varios documentos de pruebas en la tabla que creamos previamente (unos 1.500 para probar), la carpeta contiene una lista de ficheros similar a esto:

Estos ficheros no tienen extensión ni ningún tipo de vínculo con el documento original. Por eso es importante guardar en la tabla algunos de los metadatos del fichero original, ya que si no es imposible saber que tipo de documento es, ni como visualizarlo (ni mucho menos editarlo). También es importante resaltar que estos ficheros no pueden ser accedidos directamente a través de la red local. A todos los efectos los datos es como si estuviesen físicamente dentro de la tabla, en el fichero MDF.

Las grandes ventajas de este enfoque respecto a la alternativa ‘clásica’ de almacenar sólo la ruta de acceso a los documentos, y tener éstos en una ubicación de red son a mi juicio:

Atomicidad: Al fin tenemos un mecanismo que asegura que un registro y un fichero NTFS van a comportarse como una sola entidad, garantizando plenamente su integridad, olvidándonos de mecanismos de sincronización (con todo lo que conlleva).
Seguridad: La seguridad se gestiona desde SQL Server, con los usuarios y roles de SQL Server (independientemente de si usamos seguridad integrada o de SQL Server). Podemos olvidarnos de crear listas ACL separadas para controla los accesos a los ficheros NTFS.
Backups: Esto no se paga con dinero. Adios a tener que programar copias separadas de la base de datos y de los ficheros. Ahora al realizar un backup, SQL Server copiarà de forma automática la estructura de carpetas (y la restaurará, que es lo más importante).

Pero no todo son ventajas, os recomiendo dar una ojeada a la Tabla 1 de este artículo, que nos ofrece una comparativa muy detallada entre los 3 modelos (Filesystem, varbinary(max) y FILESTREAM).

Por ejemplo, una de las cosas que es muy sencillo hacer es la visualización y edición de los documentos, cuando éstos están almacenados en una ubicación de red accesible por los usuarios de la aplicación. Si sabemos la ruta de acceso al fichero basta hacer un Process.Start y éste se abrirá con la aplicación asociada:

private void editDocument(string filename)

    Process.Start(filename);

Sin embargo utilizando almacenamiento FILESTREAM esto no es tan evidente… Pero eso lo dejo para el siguiente post.

Nos leemos pronto! :-)

Editar documentos almacenados como array de bits en SQL Server [FileStream] (1/n)

Lluis Franco — Wed, 17 Aug 2011 16:25:00 GMT

Bajo este título -a priori tan chorra-, voy a empezar una serie de posts que muestren cómo almacenar documentos (ficheros NTFS) en una base de datos SQL Server 2008 mediante el uso de FILESTREAM storage, y cómo visualizarlos y editarlos con su aplicación asociada. En realidad, ésta última parte –la edición- es la única compleja, pero me ha parecido un buen tema para empezar una serie, y así de paso retomar las viejas costumbres.

FILESTREAM Storage:

Una de las características más esperadas de SQL Server 2008 –al menos por mi parte- es el almacenamiento en FILESTREAM de grandes ficheros como array de bytes, en campos de tipo varbinary(MAX) dentro de nuestra base de datos. El punto fuerte de este tipo de almacenamiento es que en lugar de almacenar el array de bytes dentro de la tabla lo almacena de forma transparente en el sistema de ficheros NTFS, pero con todas las ventajas de SQL Server (Atomicidad, facilidad para realizar backups, rendimiento, seguridad, etc.). Esto permite además que el tamaño de la BD no crezca despesuradamente, ya que la edición express *sólo* permite almacenar hasta 10GB.

Configuración de FILESTREAM Storage:

Activar FILESTREAM en nuestro servidor SQL Server.
Crear una base de datos habilitada para FILESTREAM
Crear una tabla con un campo de tipo varbinary(MAX) habilitado para FILESTREAM.

Bien, supongamos que ya disponemos de nuestra base de datos y hemos creado una sencilla tabla para almacenar documentos. Algo parecido a esto:

Dónde los campos más relevantes son:

FileId: Un campo Guid que identifica cada documento guardado de forma única.
Document: El campo varbinary(MAX) en el que vamos a volcar el array de bytes de los ficheros a almacenar.
OriginalPath: En realidad no es importante, pero uno de los metadatos que vamos a necesitar más adelante es la extensión del fichero, para que pueda ser abierta con su aplicación asociada (Word, Excel, Acrobar Reader, etc.)

Vamos a ver cómo insertar documentos en dicha tabla. Nada mejor que un poco de C# y LINQ2SQL (o EF, eso es lo de menos):

using (OpenFileDialog opendialog = new OpenFileDialog())

    opendialog.Title = "Import document to database";

    opendialog.Filter = "All Documents|*.doc;*.docx;*.xls;*xlsx;*.ppt;*.pptx;*.pdf;*.txt";

    if (opendialog.ShowDialog() == System.Windows.Forms.DialogResult.OK)

        var newdoc = new FileStreamDocument();

        newdoc.FileId = Guid.NewGuid();

        newdoc.OriginalPath = opendialog.FileName;

        newdoc.Document = File.ReadAllBytes(opendialog.FileName);

        newdoc.ComputerName = Environment.MachineName;

        context.FileStreamDocuments.InsertOnSubmit(newdoc);

        context.SubmitChanges();

En el código anterior mostramos un OpenFileDialog, el usuario selecciona un fichero, leemos el contenido y creamos un FileStreamDocument para insertarlo en la BD. La belleza subyacente es que SQL Server se encargará de almacenar dichos ficheros fuera de la tabla, en el sistema de ficheros NTFS del servidor. Y además, de forma totalmente transparente para nosotros :-)

En los próximos posts veremos dónde se almacenan REALMENTE estos ficheros, cómo visualizarlos, y lo más importante de todo, cómo editarlos y guardarlos otra vez en la base de datos de forma transparente para el usuario.

Nos leemos pronto! :-D