Teniendo en cuenta la experiencia que habíamos tenido ya una en un cliente con algo parecido revisamos nuestro anterior post sobre: Como publicar un reporte embebiendo ReportViewer en una página aspx sobre IIS7, realizamos todos los pasos allí descritos, pero esto no solucionó el tema de las imágenes. Así que decimos investigar un poco más en internet y nos encontramos que este problema se presenta comúnmente cuando el sitio web se ha creado en una ruta de disco diferente a: ..\inetpub\wwwroot, debido a que la aplicación trata de buscar los recursos que corresponden al ReportViewer en la carpeta: ..\inetpub\wwwroot\aspnet_client\system_web\2_0_50727

Así que una solución muy útil y práctica para este caso fue copiar la carpeta aspnet_client dentro de la carpeta de la aplicación, de tal forma que ahora está también en una ruta como esta: D:\\MiAplicacionWeb\aspnet_client

El truco nos funcionó, pero de repente no es la solución no es la solución más idónea para el tema, así que si alguien conoce alguna otra forma de hacerlo, por favor ¡cuéntenos! nos gustaría mucho que la compartiera aquí.

Hoy me doy cuenta que esto fue un gran error que no me permitió avanzar al ritmo que quería y al empezar una compañía en este mismo sector tuve que aprenderlo todo ya en el campo de batalla. De ahí que nuestra premisa en 3Metas desde el primer día ha sido entender el negocio del cliente a tal nivel de detalle que eso apalanque el éxito del mismo.

Esto no sólo es una ganancia para la compañía, por la oportunidad de que sus empleados aprendan cosas diferentes a las de su oficio, sino también para el cliente que puede contar con un equipo más involucrado con su negocio. Desde mi experiencia estos son algunos de los beneficios a resaltar una vez se logra esta habilidad.

• Mayor participación en las decisiones cruciales para el proyecto.
• Más alternativas en el momento de solución de los problemas.
• Mayor entendimiento de los requerimientos de los usuarios.
• Mejor relación con los usuarios que tienen la información.
• Mejor relación con los implicados en el proyecto, tanto los usuarios finales como aquellos que toman las decisiones que afectan el proyecto.
• Una oportunidad para seguir trabajando con el cliente o aplicar en proyectos similares.
• Fortalecimiento del trabajo en equipo y un mejor seguimiento del proyecto.
• Avances significativos  y menor número de retrocesos en las entregas parciales.
• Una ficha que jugarse en los momentos difíciles o de crisis del proyecto.

Es posible que se me escapen más aspectos, sin embargo mi intención es motivar a que las empresas se preocupen por apropiarse del negocio del cliente. Esto implicará dedicar más tiempo, mejorar el proceso de reclutamiento, involucrar al cliente más en el proyecto y estar consientes que esa actitud puede marcar la diferencia para triunfar como empresa, para abrirse mercado y para ser reconocidos como unos verdaderos expertos.

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">

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.

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.

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.

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.