Esta semana cuando uno de nuestros clientes estaba realizando las pruebas de un proyecto en asp.net que tenía un conjunto de reportes embebidos, las imágenes del toolbar del Crystal ReportViewer no se mostraban o se perdían.

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í.

Uno de los clientes de 3Metas tiene una base instalada muy importante de aplicaciones construidas en Visual Fox Pro 7, 8 y 9. Durante los últimos meses hemos trabajado en conjunto para desarrollar una estrategia de migración de estas aplicaciones hacia una arquitectura orientada a servicios (SOA) construida con WCF y el Framework 3.5 de .Net.

Uno de los aspectos claves de un proceso como estos consiste en evitar al máximo que se siga construyendo funcionalidad en Visual Fox Pro (VFP) así que el primer paso de la estrategia consiste en la integración de VFP con servicios de Windows Communication Foundation (WCF) de forma tal que las aplicaciones actuales se vean beneficiadas de las mejores en la lógica de negocios o de nuevas funcionalidades que se construyen con la última tecnología disponible.

1. Lo primero que debe hacerse es construir un servicio de WCF en lo que no profundizare especialmente.

2. En nuestro caso una vez que tuvimos construido el servicio construimos una fachada para su utilización desde VFP.

3. En esta fachada establecemos las referencias a los servicios por medio de la herramienta de Visual Studio, allí verificamos el tipo de conversión que se realizará sobre las colecciones genéricas. Como queremos proteger la inversión del cliente en este proyecto esta fachada deberá poderse usar desde VFP pero también desde aplicaciones desarrolladas con .Net hoy y en el futuro.

4. Creamos una clase que estará visibles por COM desde VFP y que será la fachada para esta herramienta.

5. Esta clase debe estar decorada como COM visible [ComVisible(true)] y para asegurar las opciones de Intellisense también agregamos la decoración de generación de la Interfaz [ClassInterface(ClassInterfaceType.AutoDual)]

6. Aunque visual Studio 2008 (VS2008) crea el constructor de forma predeterminada preferimos asegurarnos así que agregamos el constructor, tener presente aquí que el constructor no puede sobrecargarse ni recibir parámetros para evitar problemas en COM

7. Luego creamos los métodos que serán consumidos por VFP y se los decora como visibles para COM [ComVisible(true)].

8. En nuestro caso los métodos del servicio de WCF devuelven colecciones genéricas de tipos específicos, por ejemplo la colección de colores de la entidad color: [CollectionDataContract(Name = "Colores", Namespace ="http://myDomain.com/Data/2010/01")] public class Colores: Collection<ColorEntity> {}, para que estos métodos puedan ser consumidos desde VFP y teniendo en cuenta la restricción de COM para el manejo de genéricos se realiza una modificación al método para que no retorne la colección sino que retorno un arreglo de objetos que es algo que si puede ser manejado por VFP, la posibilidad de convertir la colección genérica en un arreglo se adiciono con LINQ, así que debe establecerse la referencia a LINQ en el proyecto y la clase, al final debe quedar algo como esto:

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.Text;

   5:  using System.Runtime.InteropServices;

   6:  using ServicioProducto;

   7:  

   8:  namespace ServicesFacade

   9:  {

  10:  

  11:      [ComVisible(true)]

  12:      [ClassInterface(ClassInterfaceType.AutoDual)]

  13:      public class ProductoFacadeVFP

  14:      {

  15:          //default constructor

  16:          public ProductoFacadeVFP() {}

  17:  

  18:          /// <summary>    

  19:          /// Metodo trae los colores del Sistema

  20:          /// </summary>

  21:          /// <returns></returns>

  22:          [ComVisible(true)]

  23:          public Color[] GetColores()

  24:          {

  25:              Colores colores = null;

  26:  

  27:              try

  28:              {

  29:                  ServicioProductoClient srv = new ServicioProductoClient();

  30:                  colores = srv.GetColores();

  31:                  srv.Close();

  32:              }

  33:              catch (Exception ex)

  34:              {

  35:                  throw ex;

  36:              }

  37:  

  38:              return colores.ToArray();

  39:          }

  40:       }

  41:  }

9. Al compilar este proyecto se obtendrá una DLL y un archivo de configuración que corresponde a la forma como se establecerá la comunicación con el servicio (Address y Bindings), estos dos archivos son los que deben entregarse a los desarrolladores de VFP para que consuman los servicios.

Completada la fase de preparación y construcción de los servicios y su fachada los desarrolladores de VFP ya pueden integrar estos componentes en sus aplicaciones, para ello deben realizarse las siguientes actividades:

1. Registrar la Interfaz COM de la fachada de los servicios por medio del comando regasm, idealmente debería utilizarse el parámetro CODEBASE, la instrucción sería algo como esto si se corre desde el directorio del Framework 2.0 de .Net: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>RegAsm.exe “C:\3Metas\Clients\Cliente\Proyecto\ServiceFacade\ ServicesFacade.dll” /CODEBASE

2. Uno de los aspectos más importantes de WCF es la separación de la configuración del servicio del código, el address y el binding del servicio que están definidos en el archivo de configuración, este archivo de configuración se generó al compilar la fachada. Para cada proyecto en el que va a utilizarse la fachada se debe copiar el archivo de configuración del servicio en la misma ruta del ejecutable de la aplicación de VFP o para depuración en la ruta donde reside el proyecto, este archivo debe renombrarse con el nombre de la aplicación de VFP y la extensión .config, en nuestro caso queda algo como esto: aplicaciondelcliente.exe.config. Muchos de los errores que se pueden presentar al usar la fachada tienen que ver con el hecho de que la aplicación no encuentra el archivo de configuración.

3. Registrada la interfaz COM de la fachada y renombrado y ubicado correctamente el archivo de configuración del servicio ya está todo listo para que el desarrollador pueda utilizar los servicios desde VFP. Solo debe utilizar el método CREATEOBJECT con el nombre de la clase de la fachada. Por ejemplo:

   1:  LOCAL Colores

   2:  LOCAL MyColor as ServiceFacade.ServicioProducto.Color

   3:  LOCAL ProductoFacade as ServicesFacade.ProductoFacadeVFP

   4:  

   5:  ProductoFacade = CREATEOBJECT("ServicesFacade.ProductoFacadeVFP")

   6:  Colores = ProductoFacade.GetColores()

   7:  

   8:  OPEN DATABASE "C:\3Metas\Clients\Integration\sampledata" EXCLUSIVE

   9:  USE color IN 0 EXCLUSIVE ALIAS tblColor

  10:  ZAP

  11:  

  12:  FOR EACH Item IN Colores

  13:      INSERT INTO color (ColorId) VALUES (Item.ColorId)

  14:  ENDFOR

Listo, el equipo de desarrolladores de VFP está consumiendo servicios de WCF.

Aclaraciones importantes:

· Con Visual Fox Pro se pueden consumir servicios Web, así que si se exponen los servicios de WCF con un binding básico HTTP el servicio de WCF se ve exactamente igual que un servicio web y por tanto se consume sin problemas desde FoxPro, sin embargo desde la perspectiva técnica puede llegar a tener problemas con objetos de negocios que VFP no entienda o que el servicio de WCF este expuesto por otro binding lo que haría imposible consumirlo desde VFP nativo, en nuestro caso las aplicaciones no estaba construidas consumiendo servicios web y el cliente no quería invertir tiempo de los desarrolladores en que aprendieran a consumir servicios web desde VFP, de allí tenía sentido que ellos consumieran objetos COM que les son familiares.

Al crearse el proyecto de fachada podría configurarse por medio de VS2008 la conversión de las colecciones genéricas en arreglos (ARRAYS). Sin embargo, eso haría que la fachada perdiera tipos de datos que podrían ser utilizados por clientes de .Net

Complemento de otro post en el que Roberto Alvarado ya había hecho un abrebocas del tema.

En IIS7 se pueden usar otros bindings como por ejemplo net.tcp y named.pipes para acceder a servicios de WCF (en IIS6 sólo es posible usar http Binding, para usar uno de los otros se debe hostear el servicio en otro tipo de host como un servicio Windows o una aplicación de consola) y justo esto es una de las ventajas de IIS7, se utiliza todo lo bueno del mundo del IIS como el reciclaje de aplicaciones pero con protocolos muchos mejores para ciertos escenarios como net.tcp.

Para habilitar estos protocolos en IIS7 debe ir al panel de control, programs, turn Windows Features On/Off y verificar que tenga seleccionadas por lo menos las opciones que aparecen en la imagen, en especial lo que tiene que ver con la activación de servicios sobre protocolos no HTTP.

Con esta habilitado ya se puede ir al IIS y seleccionar los bindings y protocolos correctos como se muestra en las dos imágenes siguientes:

Ahora puede Hospedar servicios de WCF con bindings como net.tcp que se usa para escenarios de red de área local o named.pipes que se usa para comunicaciones interprocesos en la misma máquina.

En 3Metas utilizamos las últimas tecnologías en desarrollo de software, por eso muchas de nuestras aplicaciones trabajan bajo la arquitectura de servicios (SOA).  Por esta razón en uno de nuestros clientes usamos servicios de Windows Communication Foundation para compartir datos entre diferentes plataformas y aplicaciones como por ejemplo Windows Mobile, Aplicaciones WPF, Aplicaciones Silverlight y ASP.NET.

Una de las tareas que debemos realizar después de crear estos servicios es la publicación de los mismos en un servidor web para que sean expuestos y utilizados por las diferentes aplicaciones. En este pequeño tutorial publico los servicios en un servidor web IIS 7 con Windows Server 2008.

1. Se crea un sitio web, se le asigna un puerto específico, en el caso de nuestro cliente,  es el puerto 81 el que utilizan los servicios  WCF. Sin embargo podemos escoger cualquier puerto y verificar que este puerto este abierto en el firewall si los servicios van a  estar expuestos a internet.

2. Se copian los archivos publicados de la solución de los servicios en una carpeta específica, que es la misma que se ha definido al momento de crear el sitio web en el IIS.

3. Nos aseguramos que el namespace  ServiceModel este activo y registrado en nuestro servidor IIS, para ello abrimos la consola de comandos en modo administrador y ejecutamos el siguiente comando: “%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe” -r –y

4. La ejecución de este comando nos muestra unos resultados como parece en la siguiente figura

5. Se revisan los Handler Mappings como se ve en la figura:

6. Doble clic sobre Handler Mapping, aparece la siguiente pantalla:

7. En esta pantalla revisar si existen las entradas para la definición de los *.svc, ya que en nuestro caso los Hosting de los servicios WCF son en IIS con ASP.NET.

8. Para crear estos handlers hacemos clic derecho sobre la lista, nos muestra el siguiente menú:

9. Seleccionamos la primera opción  Add Managed Handler que nos muestra la siguiente pantalla en la cual colocamos los datos a ingresar:

8. Los valores a colocar para Request path: *.svc, Type: System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Name: svc-Integrated. Las restricciones las dejamos por default. Este es el primer registro. Debemos colocar otros 2 registros.

9. Los valores a colocar para Request path: *.svc, Type: %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll, Name: svc-ISAPI-2.0. Las restricciones las dejamos por default. Este es el segundo registro.

10. Los valores a colocar para Request path: *.svc, Type: %SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll, Name: svc-ISAPI-2.0-64. Las restricciones las dejamos por default. Este es el tercer registro si es para un servidor de 64 bits.

11. Luego verificamos si nuestros servicios quedaron funcionando de manera correcta, en la pantalla siguiente:

12. Seleccionamos un servicio, como el que se muestra en la figura, clic derecho y en el menú que aparece le damos Browse, lo cual nos abre una ventana del explorador de internet para verificar si nuestro servicio está funcionando de manera correcta.

13. El explorador de internet nos debe mostrar una pantalla como la siguiente: indicando que el servicio está funcionando correctamente.

14. El siguiente paso es corregir en el web.config del sitio ASP.NET que hostea u hospeda  los servicios WCF, las cadenas de conexión a las bases de datos que utilizamos para que nuestros servicios puedan funcionar de manera correcta.

En nuestro caso verificamos la sección ConnectionStrings del web.config y colocamos los valores correctos:       <connectionStrings>

<add name=”XXXXXNETDB” connectionString=”Data Source=YYYYY;Initial Catalog=MiBaseDatos;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

<add name=”XXXXXNETDBII” connectionString=”Data Source=YYYYY;Initial Catalog=MiOtraDB;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

<add name=”ZZZZDB” connectionString=”Data Source=YYYYY;Initial Catalog=JJJJJJ;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

</connectionStrings>

15. El siguiente paso es ir a la solución que consume los servicios que estamos exponiendo en el IIS en nuestra solución ASP.NET a través de los archivos *.svc  y colocar la dirección correcta de cada uno de los servicios en el app.config si es una aplicación  Windows, o en el web.config si es una aplicación web.

Verificamos y cambiamos el endpoint de los Servicios WCF que estemos exponiendo en nuestra aplicación :

<endpoint address=”http://servidor:81/ServicioRendimientos.svc”

binding=”wsHttpBinding” bindingConfiguration=”WSHttpBinding_IServicioRendimientos”

contract=”ServicioRendimientosClient.IServicioRendimientos”

name=”WSHttpBinding_IServicioRendimientos”>

<identity>

<dns value=”localhost” />

</identity>

</endpoint>

16. Como podemos observar en el tag address=http://servidor:81/ServicioRendimientos.svc, hemos cambiado a servidor:81 que es el nombre del servidor y el puerto por donde definimos en el sitio que se va a exponer los servicios WCF.

17. Probar nuestra aplicación que consume los servicios para comprobar que todo esté funcionando como debe ser.

Bueno eso es todo por ahora, espero haber podido ayudarles en este proceso de instalación de los servicios WCF en un servidor IIS.

En 3metas estamos automatizando el sistema de post cosecha de una de las empresas floriculturas más grandes del país. Nuestro mayor reto ha sido crear un sistema que permita facilitar la transición del papel a un software a la medida que resulte fácil de usar para unos usuarios muy particulares: los empacadores de ramos. Usuarios cuyo contacto más cercano con la tecnología son sus celulares, usados casi estrictamente para recibir y hacer llamadas.

Hoy tenemos un inconveniente con ellos que afecta una parte del proceso. El caso es el siguiente: hay necesidad de leer un serial para lo cual cada usuario cuenta con un lector de seriales (como el de los supermercados) que le ayuda a ingresar los datos del producto. Estos seriales, como también ocurre en los supermercados, muchas  veces no alcanzan a ser leídos por las máquinas y hay que ingresarlos manualmente.

Allí radica nuestro problema, pues el sistema está compuesto por dispositivos móviles (PDA) que no cuentan con un teclado. Ergo, todo es touch screen y los teclados están incluidos, en digital, dentro del programa. Pensando en esto usamos el teclado alfanumérico, tipo qwerty que ven a continuación. Sin embargo en la práctica hemos notado una dificultad en los usuarios para encontrar las letras pues en su imaginario “están en desorden”. Nuestra primera conclusión es que los números junto con las letras generan ruido y esto hace que sea más difícil encontrar lo que se busca.

Por ellos pensamos usar un teclado qwerty normal como el del Iphone, pero esta solución no es viable porque todos los seriales están compuestos por números y letras, así que toma mucho tiempo cambiar repetidamente de teclado, uno para números y otro para letras. Hemos pensado dejar el teclado como está hoy y organizar las letras alfabéticamente, pero tenemos dudas de generar recordación de un teclado que sólo se usa para esto o crear más confusión a largo plazo cuando los usuarios tengan contacto con un computador y por ende con un teclado qwerty.

Sabemos que la situción tiene varios limitantes, pero creemos que reparar en estos detalles nos alimenta. Cuéntenos qué se les ocurre, qué soluciones le verían esto.

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)