Las ventanas de Windows (formularios Windows Forms) se pueden cerrar bien por parte del usuario, bien mediante programa con el método Close(). Pero ¿cómo distinguir ambos casos?

En Visual Basic 6 era muy fácil hacerlo dentro del evento QueryUnload gracias al parámetro UnloadMode. Sin embargo en .NET no es tan sencillo averiguarlo. Hoy nos ha surgido la necesidad en un trabajo y lo cierto es que no tenía ni idea ya que suelo trabajar más con WebForms, que no se cierran ;-)

Aunque no es tan flexible como el evento QueryUnload mencionado esta solución hace el trabajo.

Se trata de subclasificar el procedimiento de la ventana (mira mi post sobre Subclasificación de ventanas en .NET) y verificar que el mensaje que se está produciendo es WM_SYSCOMMAND con el parámetro SC_CLOSE, así:

public const int SC_CLOSE = 0xF060;
public const int WM_SYSCOMMAND = 0x0112; 
 
protected override void WndProc(ref System.Windows.Forms.Message m)
{ 
      if(m.Msg == WM_SYSCOMMAND && (int)m.WParam == SC_CLOSE) 
           //La cerró el usuario
      base.WndProc(ref m); 
 }

Si queremos podemos cancelar el proceso del mensaje para cancelar el cierre de la ventana en caso de que sea el usuario quien lo haya provocado (hay situaciones en las que puede ser muy útil).

Si, al igual que yo, eres de los maniáticos del orden y la claridad (sobre todo cuando programas) este programa te va a encantar. Se trata de un complemento (add-in) para Visual Studio .NET 2003 que permite gestionar de forma sencilla cómo se coloca el código dentro de regiones, tanto con C# como con VB.

Tras haberlo instalado cuando seleccionemos cualquier porción de código podremos hacer que éste pase a formar parte automáticamente de una nueva sección o bien de una existente. soporta incluso secciones anidadadas por lo que no hay pega que achacarle.

Lo puedes descargar junto con una breve explicación de su funcionamiento e instalación desde este artículo de CodeProject (excelente página, por cierto).

Me he topado con este problema ayer trabajando con un servicio Web y creo que es lo suficientemente interesante como para comentarlo aquí.

Cuando se crea un servicio Web con Visual Studio .NET empleando los Web Services Enhancements 2.0 (para seguridad, enrutado o cualquier otra característica avanzada soportada por estos componentes), se puede producir un problema al consumir desde una aplicación cliente algún método del servicio que devuelve un DataSet tipado.

Una vez habilitado WSE 2.0 en el proyecto, al añadir una referencia Web al servicio web que vamos a consumir, se crean dos proxy a dicho servicio. Uno de ellos es el normal de toda la vida que crea Visual Studio y que se llama como el servicio que hemos añadido, y otro es un proxy que permite sacar partido a las características de WSE y que se llama NombreServicioWse (con el apéndice Wse al final).

Resulta que las versiones de WSE 2.0 anteriores a la 2.0.04168.1 generan mal el proxy y los métodos que deberían devolver un DataSet tipado devuelven un objeto XMLElement, por lo que el código falla miserablemente al intentar usar el objeto correspondiente. Habría que usar el XML directamente, todo un problema que no necesitamos.

Para asegurarte de que todo funciona como es debido verifica la versión de WSE que tienes instalada (la puedes ver en las propiedades del archivo Microsoft.Web.services2.dll) y si es inferior a la indicada antes actualízate a la más reciente, disponible en http://www.microsoft.com/downloads/details.aspx?FamilyId=FC5F06C5-821F-41D3-A4FE-6C7B56423841&displaylang=en. La versión actual es la 2.0.4189.0.

Gracias a David Carmona de Microsoft por confirmarme que esto era un 'bug'. Y gracias a Iván González porque si no me hubiera pasado el otro día en un apuro una versión antigua de WSE 2.0 no hubiera disfrutado tanto perdiendo el tiempo para ver qué diantres pasaba ;-)
(En serio, gracias Iván por pasármelo, pero actualiza la que llevas en el portátil o te puedes llevar una sorpesa).

La máxima que encabeza este artículo es bien conocida en la naturaleza. Lo que ocurre es que en .NET hay algunas clases que parece que actúen contra-natura. Bromas aparte me gustaría hacer mención aquí a un comportamiento de las cadenas de texto en .NET que, si bien bastante lógico, puede que despiste a más de uno si no se lo han hecho notar nunca.

Consideremos el siguiente código, tan sencillo:

MiClase c1 = new MiClase();
MiClase c2 = c1;

Cuando en .NET hacemos esto la variable 'c2' contendrá una referencia a 'c1'. Si ahora, por el motivo que sea, transformamos los datos encapsulados en el objeto 'c1' o incluso si cambiamos el objeto al que referencia esta variable, 'c2' seguirá siendo idéntica a 'c1', es decir seguirá referenciando el mismo objeto al que referencie a su vez 'c1'.

Sin embargo hagamos algo similar con una cadena de texto:

string s1 = "Hola Pepe";
string s2 = s1;
s1 = s1.Replace("Pepe", "Paco");
Console.WriteLine(s1);
Console.WriteLine(s2);
Console.ReadLine();

Según lo que acabamos de explicar en el párrafo anterior, al terminar de ejecutarse este código deberíamos ver escrita en la consola dos veces la frase "Hola Paco", ya que 's1' ha cambiado y 's2' referencia a 's1'. Sin embargo lo que veremos es "Hola Paco" y luego "Hola Pepe", es decir, que aparentemente la teoría ha fallado. ¿A qué es debido este comportamiento "extraño"?

La clase 'string' de .NET es algo peculiar ya que se comporta al mismo tiempo como una clase y como un valor nativo. Su mayor peculiaridad es que se trata de un tipo Inmutable. Esto quiere decir que una vez establecido el valor de una cadena éste no se puede cambiar en modo alguno. Cualquier cosa que hagamos que modifique una cadena (como cambiar parte de ésta como en el ejemplo, o concatenarle otra, etc...) lo que en realidad hace es que se genere una nueva cadena desechando la anterior, de ahí el comportamiento observado.

Y esto ¿por qué hacerlo así?

Bueno, si lo pensamos con calma veremos que es bastante lógico que así sea. Para empezar, cuanod asignamos una cadena a una variable no estamos pensando en ella como un objeto al uso sino más bien como un valor. Al hacer la segunda asignación lo normal es que se cree una copia puesto que de no ser así ambas variables estarían trabajando sobre la misma cadena y sería fuente de múltiples errores normalmente al no tratar a éstas como objetos.

Además de este motivo más filosófico existen otros de índole más práctica. El funcionamiento interno de la cadena se simplifica enormemente si se parte de la base de que ésta es inmutable. No hay que mantener una matriz dinámica u otra estructura cambiante en su seno para guardar los datos, no hay que meter coplejos algoritmos para conservar sus partes o tratarlas en modo alguno, no hay que preocuparse en realidad por demasiadas cosas: solamente se crea una nueva instancia y se devuelve, lo cual es muy eficiente.

Como contrapartida se gasta mucha más memoria (mientras no actúe el recolector de basura al menos). Es por esto que cuando se deba modificar continuamente una cadena (por ejemplo dentro de un bucle concatenándole nuevas subcadenas) es muchísimo más eficiente y rápido utilizar la clase StringBuilder, que está optimizada para almacenar cada fragmento que entre en juego en memoria y, sólo al final cuando la necsitemos generar una nueva cadena. De hecho este es el comportamiento que se usaba también en Visual Basic o en los lenguajes de Script. En nuestra empresa, muchos años antes de .NET, ya disponíamos de una clase StringBuilder propia que nos permitía trabajar concatenando grandes cadenas a una velocidad elevadísima.

En resumen

Dos ideas fundamentales:

1.- Cuidado con código similar al del ejemplo de este texto. Debe darse cuenta de que al modificar una cadena de algún modo la perderá para siempre.
2.- Si necesita generar grandes cadenas a partir de otras mucho menores o si necesita trabajar con cadenas aparentemente "Mutables" emplee la magnífica clase StringBuilder.

No por ser conceptos básicos los tenemos siempre presentes y, como me he encontrado con esta situación hace poco me he animado a recordarla aquí.

En Krasis - Grupo Femxa estamos de enhorabuena.

La revista PC World ha revisado este mes de Septiembre nuestro producto MAILController (le dedica una página completa), y tras analizarlo le ha otorgado las 5 estrellas de la revista, como producto recomendado.

MAILController permite a cualquier usuario, sin necesidad de cambiar de cuenta de correo, el envío de correo electrónico "inteligente" que le informa en tiempo real de cuándo, dónde, cuántas veces se leen sus mensajes y se descargan sus archivos adjuntos y desde qué cuentas, sin necesidad de interacción alguna por parte del receptor.

Es super-útil para enviar propuestas comerciales, notificaciones, convocatorias de reuniones e incluso Curriculums si estás buscando trabajo y quieres saber si te hacen caso...

Se puede obtener una cuenta de prueba desde la página de Krasis y también leer el artículo completo de PC World (pulsando sobre el logo 5 estrellas en la página del producto).

Este chiste lo he leído recientemente en los foros privados de MVP contado por Willy Marroquín y no me he resistido a ponerlo aquí por que, la verdad, es muy gracioso. Espero que no te importe, Willy.

Michael Schumacher llega a casa después de un duro día de entrenamiento en el circuito.
Su mujer le recibe con un beso y le pregunta:
   - "¿Cómo ha ido hoy el día, cariño?"
   - "Bueno, cuando he llegado al circuito, he ido a boxes y el F1 no estaba en su sitio. En su lugar había un burro."
   - "¿Cómo?", se sorprende la mujer.
   - "Si, así es. Le he preguntado al jefe de equipo y me ha confirmado que habían cambiado el monoplaza por el burro."
   - "¿Y tu que le has contestado?"
   - "Pues yo le he dicho que quizás no seria tan rápido como el F1. Él ha dicho que ciertamente es así, pero que ahora tenemos una ventaja y es que podremos correr en todo tipo de circuitos: F1, rally, motocross, trail sin... Y bueno, al menos hoy he podido venir montado en él hasta casa, cosa que no podía hacer con el F1."
    - "Ya. Pero si tu sólo corres en F1, ¿para que quieres poder correr en otros circuitos?"
    - "Pues no lo se, la verdad. Además, después de montarme en el burro le he dicho al jefe de equipo que no era ni la mitad de cómodo que el monoplaza."
   - "¿Qué ha respondido el?"
   - "Simplemente ha dicho que eso no importa porque ahora podemos correr en todo tipo de circuito."
   - "¡Ay Señor!, ¿Y no corres más riesgo de hacerte daño si te caes?"
   - "En realidad no, porque le han puesto al burro las mismas protecciones que tiene la cabina del F1. A pesar de que hace que todavía vaya un poco mas lento. Según el jefe eso ya no tiene tanta importancia, porque ahora podemos correr en todo tipo de circuito."
   - "Esta bien, enséñame el burro."
Tras salir al jardín y quedarse estupefacta con la imagen de un burro pintado de rojo, con el escudo de Ferrari pegado en la frente y una protección de F1 encima de la silla de montar, la mujer le pregunta a Michael:
   - "¿Y como se llama el animal?"
   - Se llama ....
   - Se llama ....
   - Se llama ....
   - Se llama ....
   - Se llama ....
   - Se llama ....
         JAVA !!!!!!!!

X-DDDDD

Según apunta Willy además no es cierto que Ferrari use Java. Los leguajes oficiales para desarrollo en el equipo Ferrari son VB.NET y C++, tal y como se indica en una entrevista concedida a CNET NEWS (muy interesante, por cierto).

El otro día estaba jugueteando con la seguridad de una aplicación Windows escrita en .NET, utilizando las clases WindowsPrincipal y WindowsIdentity para probar algunas cosas. El caso es que me parece estupendo que WindowsPrincipal disponga de un método IsInRole que nos permite saber si el usuario que representa se encuentra dentro de un grupo de usuarios o no. Sin embargo me parece un error que no ofrezca propiedad o método alguno para obtener directamente la lista de todos los grupos/roles a los que pertenece el usuario. Creo que sería mucho más cómodo en algunas situaciones, sobre todo cuando no sabemos de antemano qué roles hay disponibles.

Investigando un poco el asunto y utilizando un explorador de clases/decompilador .NET (Anakrino, en concreto) me di cuenta de que la clase WindowsIdentity dispone de un método privado llamado _GetRoles (sí, con guión bajo delante) al que se le debe pasar el token de un usuario y que devuelve una matriz de cadenas de texto. Tiene toda la pinta de servirme par alo que yo quería, así que, digo yo, mediante reflexión será muy sencillo llamarla y ver qué pasa: ¡Voilà!, ¡funcionó!. Esta función es estática (Shared en Visual Basic) en la clase WindowsIdentity y permite obtener una lista con los grupos de usuario a los que pertenece un usuario representado por su Token. Basándome en esto creé una función que, pasándole un objeto WindowsIdentity devuelve una lista de grupos de usuario a los que pertenece. Funciona tanto en autenticación local como contra Active Directory. Este es el código completo con un ejemplo de uso que averigua los roles del usaurio actualmente autenticado en un sistema y los muestra a través de la consola:

Hoy me he enterado de que está accesible al público (aunque no publicitada) la versión Beta de la nueva documentación en-línea de la plataforma .NET 2.0.

Se trata de la documentación y referencia de "Whidbey", o sea, de .NET 2.0, pero tiene una característica muy interesante: basta con escribir "http://msdn2.microsoft.com/library/<namespace>.aspx"  para que aparezca la documentación del espacio de nombres indicado. Así, por ejemplo, puedes escribir "http://msdn2.microsoft.com/library/System.Configuration.aspx"  para que aparezca la documentación de las clases de configuración de la plataforma. Puedes seguir profundizando e incluir a continuación nombres de clases concretas e incluso nombres de métodos.

Por ejemplo, si pones http://msdn2.microsoft.com/library/System.Security.Cryptography.MD5.Create.aspx obtendrás la documentación (aún en pañales) del método 'Create' de la clase 'MD5' para cálculo de huellas digitales con este algoritmo.

Ni que decir tiene la utilidad de algo así para ofrecer ayuda contextual en aplicaciones y utilidades de programación propias.

Hoy he estado viendo de nuevo un breve análisis sobre la seguridad de los sistemas operativos que publicó hace unos meses la conocida página Zone-h.org, especialista en seguridad de Internet.

En este artículo se muestran unas gráficas de evolución de ataques durante un año, sufridos por diversos sistemas operativos, y cuya mayor relevancia se obtiene al comprobar los valores para las familias de sistemas Windows y Linux. De hecho si se analizan las gráficas con detenimiento se ve que Windows gana a Linux por goleada la mayoría de los meses.

Tal y como apuntan los autores del portal, quedarse en estas meras cifras sería pecar de cortos de miras, puesto que éstas dependen de multitud de factores (incluso de las modas: hay épocas que a los crackers se les da por atacar un sistema determinado en lugar de otros). Sin embargo estas cifras son bastante significativas desde mi punto de vista. Incluso se puede comprobar cómo los ataques con éxito sufridos por Windows 2003 frente a windows 2000 son muchísimo menores, como era de esperar. Todo un síntoma ¿no?

La página llega a una conclusión con la que estoy completamente de acuerdo y que además no me canso de repetir en artículos, charlas, cursos y demás foros en los que participo: si bien es muy importante, la seguridad del sistema operativo y de la red no sirve absolutamente de nada si nuestras aplicaciones están escritas con código inseguro (algo que pasa en las mejores empresas, te lo puede certificar cualquiera).

El que va por la vida afirmando sin duda posible que un determinado sistema es inherentemente seguro (o inseguro), o bien no sabe de qué está hablando o miente descaradamente, o ambas cosas. Es cierto que un sistema operativo bien configurado, un buen cortafuegos, IDS, y demás parafernalia de seguridad son indispensables. Ahora bien, ya puedes tener lo mejor de lo mejor en este aspecto, que si tu aplicación está mal escrita y no tiene en cuenta las cuestiones fundamentales sobre escritura de código seguro todo ello no sirve de nada.

En este sentido una buena formación es indispensable. Durante todo el año pasado algunas personas impartimos formación sobre este aspecto concreto de la programación para MSDN. Lo que más me llamó la anteción de estas charlas en las encuestas informales a mano alzada que hice fue la cantidad de programadores curtidos que no habían oído hablar de desbordamientos de búfer, de inyección SQL, XSS, etc...
Y es especialmente alarmante (y esto lo veo en mi trabajo, no en charlas informales) la cantidad de programadores profesionales que jamás tienen en cuenta aspectos relativos a la seguridad cuando desarrollan una aplicación. La opinión más extendida para evitar pensar en ello suele ser: "Ya se ocuparán de proteger los servidores los chicos de sistemas". Craso error.

Espero que esto cambie con el tiempo. Y, mucho ojo, no se trata de algo específico o ligado a plataformas Microsoft, Linux o cualquier otra. Es independiente de la tecnología y está relacionado íntimamente con la calidad del código y la formación específica de quien lo desarrolla.

¡Ahí queda eso! ;-)

Una reminiscencia de mi etapa como ingeniero mecánico ;-)

Este software estaba en mi anterior página y, al crear este Blog desapareció. El caso es que estaba bastante demandado dado que lo usan en algunas universidades para práctica de tecnología mecánica, por lo que he decidido volver a ponerlo aquí en el apartado de Freeware.

Este software sirve para simular procesos teóricos de corte ortogonal (fresado, torno, cepillado, etc..). Tiene un interfaz gráfico muy intuitivo que permite variar de manera contínua las condiciones del corte, reflejándose automáticamente los cambios en los cálculos y la representación gráfica. Permite escoger la teoría de corte a utilizar, los parámetros fijos, unidades, etc.. y representa el diagrama del proceso descomponiendo todas las fuerzas y velocidades en sus componentes más importantes. Facilita más de 30 variables del corte y permite imprimir los resultados y/o exportarlos a Microsoft Excel (necesitas tener instalado Excel para esto).

Con la instalación incluye un manual en PDF que explica el proceso de cálculo realizado por el programa, tiene un resumen de ecuaciones empleadas, etc... y puede resultar de interés para alumnos de ingeniería mecánica.

Puedes descargarlo pulsando aquí (1.66 MB).

En mi "post" del día 31 de agosto (Cómo utilizar los estilos visuales de Windows XP) explicaba cómo habilitar los estilos visuales de Windows XP en aplicaciones Windows Forms con la versión 1.1 de la plataforma .NET. Por los comentarios que he recibido estos últimos días deduzco que vendría bien dar algunos consejos más.
En concreto me han planteado las siguientes dudas:

1.- ¿Tengo que tener todos los controles con FlatStyle = System?

Sí. Es necesario o sino no se verán con el estilo de Windows XP. Así que no queda más remedio que fijar esta propiedad en todos los controles que dispongan de ella.

2.- Menudo aburrimiento recorrer uno por uno los controles para fijar esta propiedad... ¿Puedo hacer otra cosa?

Sí, puedes automatizar esta tarea. Me he tomado la libertad de escribir una pequeña rutina que hará precisamente esto. La he escrito en Visual Basic por probarla en un proyecto que estamos haciendo ahora en la empresa y que es en este lenguaje, pero traducirla a C# no reviste dificultad alguna:

Class clsVisualStyles

  Private Sub New()
    'No hace nada. Lo creo así, privado, para que no se pueda instanciar
  End Sub

  'Cambia los estilos de botones, etiquetas y grupos (y derivados) para que se adapten a Visual Styles de Windows XP
  'Hay otros controles que se adaptan automáticamente
  Public hared Sub ChangeFlatStyle(ByVal frm As Control)
    Dim ctl As Control
    For Each ctl In frm.Controls
      If TypeOf ctl Is ButtonBase Then
        CType(ctl, ButtonBase).FlatStyle = Windows.Forms.FlatStyle.System
      ElseIf TypeOf ctl Is Label Then
        CType(ctl, Label).FlatStyle = Windows.Forms.FlatStyle.System
      ElseIf TypeOf ctl Is GroupBox Then
        CType(ctl, GroupBox).FlatStyle = Windows.Forms.FlatStyle.System
      End If

      'Si el objeto es contenedor llamamos a esta misma función recursivamente
      If ctl.Controls.Count > 0 Then ChangeFlatStyle(ctl)
    Next
  End Sub
End Class

De este modo sólo es necesario llamar a este método estático desde el método InitializeComponent o desde el evento Load de cualquier formulario pasándole un referencia a si mismo:

clsVisualStyles.ChangeFlatStyle(Me)

Se recorrerán todos sus controles y los hijos de éstos recursivamente (gracias Germán por hacérmelo notar) para modificar su propiedad FlatStyle. Dado que no todos los controles disponen de dicha propiedad es necesario hacerlo de esta forma ya que sólo los controles que heredan de ButtonBase, Label o GroupBox la poseen. Si a alguien se le ocurre un método mejor agradecería mucho que me lo hiciese llegar.

3.- ¿Y cómo hago para habilitar los estilos si uso la versión 1.0 de .NET?

En el anterior "post" ya apuntaba la forma de hacerlo: mediante un archivo '.manifest' con el nombre de nuestra aplicación. Por ejemplo, si disponemos de una aplicación llamada 'MiApplicacion.exe' y queremos que obtenga los estilos visuales de XP debemos crear un archivo de texto de nombre 'MiAplicacion.exe.manifest' cuyo contenido debe ser análogo al siguiente:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly 
xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <assemblyIdentity 

                name="CryptDecrypt 
Util"
                processorArchitecture="x86"
                version="1.0.1689.32606"
                type="win32"
        />

        <description>Utilidad 
de criptografía de KWAF</description>

        <dependency>
                <dependentAssembly>
                        <assemblyIdentity
                                type="win32"
                                name="Microsoft.Windows.Common-Controls"
                                version="6.0.0.0"
                                processorArchitecture="x86"
                                publicKeyToken="6595b64144ccf1df"
                                language="*"
                        />
                </dependentAssembly>
        </dependency>
</assembly>

He marcado en rojo las etiquetas que hay que cubrir obligatoriamente con el valor adecuado y en granate las que son opcionales pero de exisitr deberíamos cubrir de forma adecuada. Su significado es evidente.
OJO: No llega sólo con crear este archivo y copiarlo a la carpeta de la aplicación. Al igual que en el caso de la versión 1.1 es necesario cambiar la propiedad FlatStyle de los controles a System o no se verán los estilos visuales, por lo que la clase del punto 2 resultará igual de mucha utilidad.

Si, al igual que yo, usted tiene que trabajar con un portátil en diversas localizaciones encontrará este truco muy útil.

Cada vez que voy a la oficina de un cliente con mi portátil tengo que cambiar la configuración de la tarjeta de red para asignarle los parámetros adecuados: dirección IP, máscara de sub-red, puerta de enlace, etc... para así poder "engancharme" a la red local del sitio en el que esté. Al salir y volver a mi oficina o a la de otro cliente toca repetir la misma operación. Si esto hay que hacerlo cada dos por tres se convierte en una tarea muy tediosa ya que normalmente hay que apuntar en algún archivo toda esta información e introducirla a mano.

Es posible, sin embargo, automatizar el proceso de la siguiente manera (esto es algo que utilizo habitualmente):

La próxima vez que tenga que cambiar la configuración de red tras haber realizado el cambio abra una línea de comandos y escriba:

netsh dump >> c:\Configuración_Cliente_A.txt

Esto creará un archivo de comandos en C:\ con las instrucciones necesarias para recrear la configuración de red actual. Repita este proceso con todos los clientes o ubicaciones en los que tenga que cambiar su configuración.

Ahora, con estos archivitos será facilísimo cambiar la configuración de la red de forma automática. Por ejemplo, si tras dos semanas vuelve a la oficina del cliente "A", sólo tiene que escribir:

netsh exec c:\Configuración_Cliente_A.txt

Al hacerlo el comando netsh ejecutará el script creado automáticamente antes y reconfigurará de forma automática la conexión a la red. De este modo cada vez que tenga que conectarse a una red diferente sólo tendrá que ejecutar este comando con el archivo de configuración adecuado para, en cuestión de unos segundos, poder conectarse sin problemas a la red en la que esté.

Por cierto, esta técnica funciona en Windows 2000/XP/2003.

MSDE es la alternativa gratuita a SQL Server ya que ofrece toda la funcionalidad de éste pero, eso sí, limitada en cuanto a tamaño de las bases de datos y número de usuarios simultáneos. En fin, a estas alturas de la vida creo que no vale la pena abundar más sobre ella ya que es de sobra conocida (por si acaso hay algún despistado puede echar un vistazo aquí: http://www.microsoft.com/sql/msde/).

El caso es que entre otras limitaciones de MSDE está la de que no incluye herramientas gráficas de gestión de las bases de datos, por lo que hay que utilizar alternativas (gratuitas o no) o bien las herramientas cliente de SQL Server si disponemos de una licencia.

Últimamente estoy trabajando mucho con Oracle (por necesidad, no por devoción) y para este gestor existe una herramienta para Windows llamada TOAD que es realmente impresionante y desde luego mucho más potente que las que vienen "de fábrica" con el producto. El caso es que Quest, la casa que fabrica esta utilidad, dispone también de un TOAD para SQL Server que, si bien dista mucho de la capacidad de TOAD para Oracle, es muy útil y vendrá muy bien a los usuarios de MSDE que no disponen de otras herramientas adecuadas.

Ofrece principalmente las siguientes características:

• Navegador de datos: permite navegar por toda la estructura del servidor y trabajar directamente con los objetos existentes en él, creándolos, modificándolos, exportándolos, etc... Automatiza la creación de scripts, permite gestionar disparadores y procedimientos almacenados, etc... Muy útil.
• Editor SQL: para crear, ejecutar, modificar, guardar, etc... consultas y procedimientos.
• Herramienta de exportación: para exportar datos directamente a archivos CSV.
• Combinación de conexiones: para trabajar desde un sólo proyecto de TOAD con varios servidores de datos a la vez.

Puedes encontrar más información y descargarlo desde aquí: http://www.quest.com/toad_for_sql_server/

Tienen una versión también gratuita para MySQL.

Microsoft acaba de poner a disposición del público el Service Pack 1 de Windows Sharepoint Services, que corrige un montón de pequeños errores y faltas del producto, aumenta su estabilidad y su seguridad. Es recomendable descargarlo e instalarlo.

Puedes encontrar toda la información sobre el asunto, y un enlace para descargarlo, en:

http://support.microsoft.com/?kbid=841876