Esta semana realizando la migración de código de un sitio web en un cliente, en el cual dentro de los múltiples cambios modificamos la interfaz gráfica de la aplicación para que utilizara Ajax e integramos además un Master Page en el diseño. Esto no debería afectar la funcionalidad, pero en especial una de las páginas empezó a presentar un problema, el cual se presentaba cuando se enviaba a realizar una operación que tarda más de 2 minutos contra la base de datos.

El error era del tipo: Sys.WebForms.PageRequestManagerTimeoutException, y por ser un error de Ajax se presentaba en el cargue de la pagina para su respectiva actualización luego de la ejecución del evento. Para resolver entonces este problema se debe incrementar el timeout para la página, y para esto se debe adicionar la propiedad AsyncPostBackTimeout al control ToolkitScriptManager o al control ScriptManager, asignándole un valor en segundos que depende del tiempo necesario para la operación.

<AT:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server" EnablePartialRendering="true" AsyncPostBackTimeout="360000" ScriptMode="Release">

El día de hoy estábamos tratando en hacer el plan de mantenimiento de la base de datos de uno de nuestros clientes con el Maintenance Plan Wizard de SQL Server 2008. Crear el plan a través de esta herramienta es bastante sencillo, pero las pocas ocasiones que lo he utilizado siempre me encuentro con algo en el momento de ejecutar el plan de mantenimiento. Dentro de las opciones del plan de mantenimiento seleccionamos la opción Reorganize Index, el cual cuando se iba a ejecutar nos presentaba un error que decía:

The index “INDEX_NAME” (partition 1) on table “TABLE_NAME” cannot be reorganized because page level locking is disabled.

El cual luego de revisar un poco en internet y la ayuda de SQL Server encontramos que se puede solucionar con la siguiente instrucción SQL:

Alter Index <index name> On <table name> Set (ALLOW_PAGE_LOCKS = ON)

Y bueno es una excelente solución, hasta el momento en que seguimos ejecutando el plan de mantenimiento y el error vuelve a aparecer una y otra vez para diferentes índices, así que decidimos buscar una nueva solución, en la cual gracias al poder de T-SQL y de internet construimos el siguiente query que nos permite realizar un SQL dinámico para cada uno de los índices con el mismo problema:

SET NOCOUNT ON
DECLARE @DBName nvarchar(50), @INName nvarchar(50)
DECLARE @ODBName nvarchar(50), @OINName nvarchar(50)
Declare @execstr nvarchar(200)
--PRINT '-------- Index with page level locking disabled --------'
DECLARE Index_cursor CURSOR FOR
SELECT idx.Name AS InName, sch.Name + '.' + obj.Name AS DBName
FROM sys.indexes idx left outer join sys.objects obj ON
obj.object_id = idx.Object_id left outer join sys.schemas sch ON
obj.schema_id = sch.schema_id
WHERE allow_page_locks=0 and obj.type='U'
-- Select only allow_page_locks 0 and User Tables
OPEN Index_cursor
FETCH NEXT FROM Index_cursor
INTO @INName, @DBName
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT @DBName +' ' + @INName
--PRINT @INName
SET @ODBName = ltrim(rtrim(@DBName))
SET @OINName = ltrim(rtrim(@INName))
SELECT @execstr = 'ALTER INDEX ' + @OINName + ' ON ' +
@ODBName + ' SET (ALLOW_PAGE_LOCKS = ON)';
EXEC (@execstr);
FETCH NEXT FROM Index_cursor
INTO @INName, @DBName
END
CLOSE Index_cursor
DEALLOCATE Index_cursor

Luego de haber solucionado el problema de los índices nos encontramos con que el tamaño del log de eventos de la base de datos era demasiado grande, y excedía el tamaño disponible en la unidad de disco donde se encontraba, así que luego de buscar un poco en internet nos encontramos con este post muy útil para solucionar este problema.

Muchos de los problemas que se presentan en el proceso de desarrollo de parte de la base de datos tienes que ver con los formatos de fechas y estos principalmente están dados por el lenguaje de la base de datos o el Collation establecido para esta. Por ejemplo, algunos de los errores comunes es:

La conversión del tipo de datos varchar en datetime produjo un valor fuera de intervalo / The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

1. El servidor de base de datos tiene un lenguaje establecido por defecto, el cual es posible visualizarlo a partir de la ventana de propiedades del servidor o a través de una consulta TSQL:

El comando sería:

SP_CONFIGURE 'default language'

Al ejecutar esta consulta en el resultado en la columna config_value nos muestra el código del lenguaje configurado por defecto en el servidor de la base de datos. Para poder saber ese código a cual lenguaje hace referencia ejecutamos el stored procedure (SP): SP_HELPLANGUAGE el cual nos dará una lista descriptiva de todos los lenguajes soportados.

Ya con esta lista podemos modificar el lenguaje configurado por defecto, el cual afectará a todos los nuevos logins que se creen de ahora en adelante. Para realizar esta modificación basta con ejecutar el SP:

USE master;

GO

SP_CONFIGURE 'default language', 5

RECONFIGURE;

EXEC sp_configure;

Donde 5 sería el identificador para el idioma español. (http://technet.microsoft.com/en-us/library/ms188787.aspx)

Luego de realizar el cambio podemos verificar este a través del procedimiento almacenado antes mencionado SP_CONFIGURE ‘default language’o a través de la ventana de propiedades del servidor de la base de datos. Cabe anotar que esta nueva configuración solo aplicará para los nuevos logins que se creen.

2. Ahora bien es posible modificar el formato Date (http://technet.microsoft.com/en-us/library/ms189491.aspx) para la sesión actual abierta a través del siguiente comando:

SET DATEFORMAT ydm

Es posible verificar los cambios en el lenguaje para la anterior instrucción al ejecutar el siguiente comando:

SELECT SYSDATETIME()

Un ejemplo muy tipico donde se presentan problemas para el formato de las fechas es el siguiente, en el cual dependiendo del formato yyyy/dd/mm la siguiente consulta puede ejecutarse satisfactoriamente:

Select DATEDIFF(Month,'2008/4/6','2008/12/31')

Si la configuración de la sesion actual esta en ingles por ejemplo, esta consulta funcionará pero si está en español nos arrojará un error del tipo:

The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

Con lo cual debemos modificar primero el tipo de lenguaje de la sesión o cambiar la consulta por:

Select DATEDIFF(Month,'2008/6/4','2008/31/12')

3. Si lo que deseamos es modificar el lenguaje la sesión actual abierta ejecutamos el SP:

SET LANGUAGE 'español'

Para poder verificar el cambio podemos realizar alguna de las siguientes consultas SQL:

SET LANGUAGE 'us_english'

SELECT CONVERT(DATETIME, '4/6/2006'),

DATENAME(weekday, '4/6/2006'),

DATENAME(MONTH, '4/6/2006')

SET LANGUAGE 'español'

SELECT CONVERT(DATETIME, '4/6/2006'),

DATENAME(Weekday, '4/6/2006'),

DATENAME(MONTH, '4/6/2006')

4. No obstante si lo que deseamos es cambiar el lenguaje de alguno de los login ya creados, con lo cual cada inicio de sesión con esa cuenta se conserve la nueva configuración del lenguaje, vamos hasta la ventana de configuración de los login creados para la base de datos o ejecutamos un comando TSQL:

El comando sería:

EXEC sp_defaultlanguage 'GustavoH-PC\GustavoH', 'español'

El cual por ejemplo para este caso está cambiando el lenguaje del login GustavoH. Con lo cual cada inicio de sesión para esta cuenta de usuario tendrá como lenguaje seleccionado español, así el lenguaje por defecto para el servidor de la base de datos sea otro.

Lo más importante en estos temas de lenguaje es saber a qué nivel queremos aplicarlos, si es a nivel de consulta, base de datos o del servidor de la base de datos, con lo cual se deberá utilizar algunas de las consultas antes definidas o realizar el cambio respectivo a través del administrador de SQL Server.

En 3Metas hemos trabajado mucho los últimos meses en el desarrollo de aplicaciones para dispositivos móviles que corren Windows Mobile. Recientemente actualizamos nuestras máquinas de desarrollo a Windows7 y hemos encontrado un problema cuando se consumen servicios de WCF.

Como sabrán para consumir un servicio WCF desde un dispositivo móvil usando el compact framework hay que crear una clase proxy utilizando la utilidad NetCFSvcUtil.exe que hace parte del conjunto power toys del compact framework 3.5 de .net.

El problema es que cuando se utiliza esta utilidad en Windows 7 siempre se produce un error como este:

Attempting to download metadata from ‘http://localhost/DinnerNow/service/DeliveryService.svc’ using WS-Metadata Exchange or DISCO.
Error: An error occurred in the tool.

Error: Error in the application.

Hay una incompatibilidad entre el tool de generación de la  clase proxy y Windows7, afortunadamente ya fue resuelto y puede obtenerse una actualización del tool desde este enlace. O se puede generar el archivo proxy en Vista o XP y pasarlo al proyecto en Windows7.

En 3Metas usamos Visual Studio Team Fundation Server como sistema de gestión de proyecto y control de versiones, sin embargo al momento de crear las soluciones cometí un error por no revisar con cuidado la guía de Branching de Patterns And Practices de Microsoft lo que me llevó a quedar con los proyectos y la documentación andando pero con un esquema incorrecto de control de código fuente. La solución es borrar (destruir) los repositorios de Código Fuente (previo backup por supuesto ) y reorganizar el sistema.

Para destruir un repositorio de código Fuente, se utiliza el comando tf destroy, (Btw: se encuentra en la ruta Program Files\Microsoft Visual Studio 9.0\Common7\IDE>) desde la consola de comandos, una confirmación de borrado aparecerá y luego se listaran los archivos y carpetas que se eliminaron.

Después de borrado puede usarse VS2008 con el Team Explorer para volver a la interfaz de gestión de los sistemas de control de código fuente y allí crear de nuevo el repositorio y configurarlo correctamente. Es importante anotar que hay que volver a asignar los permisos a los usuarios que aunque siguen teniendo permisos en el TFS en el Proyecto al que están asignados ahora no tienen permisos en el repositorio de control de versiones. Estos permisos se asignan en la pestana de seguridad de las propiedades del repositorio

(El borrado no es lo mismo, el borrado solo marca el repositorio pero sigue existiendo en el sistema se puede ver aquí: Tools > Options > Source Control > Visual Studio Team Foundation Server and check Show deleted items in the Source Control Explorer que los archivos no se borraron)

(Esto también es diferente a la eliminación del proyecto porque yo no quería perder el portal, documentos, work ítems, etc que ya se habían alimentado al sistema)

Los gadgets son aplicaciones web que se ejecutan a través del sidebar de Windows Vista y Windows 7. Su funcionalidad puede ser tan potente como la creatividad y experiencia de los desarrolladores se lo permitan. Gracias a la inclusión de JScript, Ajax y JQuery el alcance de estas aplicaciones se incrementa gradualmente.

Personalmente creo que dos de los principales inconvenientes para desarrollar este tipo de aplicaciones es lograr tener una idea que encaje en unos cuantos pixeles y realizar la depuración. Este último punto es la idea de este post.

Lo primero que debemos hacer es realizar el deployment del gadget que deseamos depurar, para esta tarea usamos Visual Studio 2008 realizando la publicación del gadget en el folder del sistema operativo donde por defecto se hospedan los gadgets:

· %USERPROFILE%\AppData\Local\Microsoft\Windows Sidebar\Gadgets (gadgets del usuario)

· %SYSTEM_ROOT%\Program Files\Windows Sidebar\Gadgets (gadgets globales)

Así que sobre el proyecto del gadget, damos click derecho y seleccionamos la opción Publish

Esto nos mostrará la ventana de publicación, en la cual colocamos en el path de publicación la ruta de instalación del gadget y seleccionamos la opción Delete all existing files prior to publish.

Una vez terminada la publicación procedemos a realizar la instalación del gadget en el sidebar dando click derecho sobre la zona de sidebar del escritorio y seleccionando la opción Agregar gadgets y agregando el que acabamos de publicar.

Con el gadget ya en el sidebar procedemos a configurar las opciones del browser para que se habilite la depuración de Scripts. Ejecutando entonces Internet Explorer, seleccionamos la opción Herramientas, seguida de Opciones de Internet y luego la pestaña Opciones Avanzadas, donde desmarcamos el check Deshabilitar la depuración de scripts (otros).

Procedemos ahora a configurar Visual Studio 2008 para iniciar el proceso de depuración. Para lo cual colocamos los break point necesarios donde deseamos que se detenga la ejecución de la aplicación y luego seleccionamos en el menú principal la opción Debug, seguida de Attach to Process.

Esto nos mostrará la ventana de procesos disponibles que actualmente se están ejecutando en el sistema operativo de nuestra máquina. En esta ventana buscamos el proceso que hace referencia al gadget que deseamos depurar y se está ejecutando en la Sidebar de Windows. Seleccionamos el proceso que hace referencia al gadget y luego damos click en el botón Attach.

Finalmente realizamos las acciones necesarias sobre el gadget que está en la sidebar para que se detenga la aplicación en los break points que hayamos establecido.

Antes de seguir los siguientes pasos, es necesario descargar Microsoft Report Viewer Redistributable.

Al realizar la publicación en IIS7 de un reporte en formato .rdlc embebido en una pagina aspx, nos encontramos que después de agregar nuestra aplicación web en IIS y dentro de su contenido copiar los archivos publicados en Visual Studio, vamos acceder a nuestra reporte (http://LocalHost/aplicacionReporte/reporte.aspx) y al realizar alguna consulta, el control ReportViewer esta deshabilitado.

La razón de esto es: cuando el control ReportViewer se añade al formulario web (Aspx), el httpHandler  Reserved.ReportViewerWebControl.axd se añade a  la sección System.Web del archivo web.config. En IIS7, este debe añadirse bajo la sección System.Webserver del archivo web.config. En IIS7 las Asignaciones de Controlador  no tiene un httpHandler del tipo Microsoft.Reporting.WebForms.HttpHandler (Reserved.ReportViewerWebControl.axd) y, por lo tanto es incapaz de habilitar los elementos del ReportViewer que necesita JavaScript.

Solución:

1. Abra Servicios de Internet Information Server (IIS) y seleccione la aplicación Web.
2. Bajo el menú IIS, haga doble clic en Asignaciones de Controlador.
3. En el panel derecho haga clic en agregar controlador administrado.
4. En el cuadro de dialogo de  agregar controlador administrado, escriba lo siguiente:

Ruta de Acceso de Solicitudes: Reserved.ReportViewerWebControl.axd

Tipo: Microsoft.Reporting.WebForms.HttpHandler

Nombre: Reserved-ReportViewerWebControl-axd

1. Haga clic en aceptar.

El manejador ó Handler, Reserved-ReportViewerWebControl-axd esta añadido ahora a su lista de asignaciones de controlador. Observe que la siguiente línea también ha sido añadida a su archivo web.config bajo la sección del manejador ó handler System.WebServer:

<add path=”Reserved.ReportViewerWebControl.axd”
verb=”*” resourceType=”Unspecified”
/>

WinMerge es una excelente herramienta para comparar archivos que puede facilitar en gran medida esta tarea en Visual Studio Team System. Aunque VSTS ya cuenta con una herramienta de comparación desde mi punto de vista no es muy práctica ni intuitiva.

Lo primero que tenemos que hacer es realizar la descarga de WinMerge la cual la pueden hacer acá. Una vez hecha la descarga, procedemos a la instalación de la herramienta.

Configuración de WinMerge en VSTS

1. Abrir Visual Studio Team System y en la barra de Menús, seleccione la opción Tools y luego Options.

2. En la ventana Options, seleccione la opción Source Control y luego Visual Studio Team Foundation Server.

3. Ahora damos Click en el botón del lado derecho Configure User Tools.

4. Este botón nos muestra la ventana para poder configurar WinMerge como herramienta de Merge y Compare.

5. Seleccionamos el botón Add y esto nos mostrará la ventana donde ingresamos la información de configuración necesaria.

6. Ingresamos la siguiente información para configurar la herramienta de Compare:

· Extension, escribir *

· Operation, seleccione Compare

· Command, seleccione el path donde quedó instalado WinMerge C:\Program Files\WinMerge\WinMerge.exe

· Arguments, escribir /e /x /s /wl /dl %6 /dr %7 %1 %2

· Click en OK para aceptar

7. Ingresamos la siguiente información para configurar la herramienta de Merge:

· Extension, escribir *

· Operation, seleccione Merge

· Command, seleccione el path donde quedó instalado WinMerge C:\Program Files\WinMerge\WinMerge.exe

· Arguments, escribir /e /s /x /ub /dl %6 /dr %7 %1 %2 %4

· Click en OK para aceptar

8. Ahora tenemos ya configurada las WinMerge como herramienta de Merge y Compare en VSTS

Con esta configuración ahora cuando necesitemos hacer tareas de Merge o Compare se harán a través de WinMerge.