Desde ayer los suscriptores de MSDN y Technet ya puede descargarse la versión definitiva de SQL Server 2008.

Se trata de una gran noticia :-)

Si eres suscriptor, ahí te dejo los enlaces:

Las versiones en otros idiomas distintos al inglés se irán colocando en las próximas semanas.

El otro día, para un proyecto, necesité disponer de una buena lista de nombres, apellidos, teléfonos y otros datos personales de individuos de distintas nacionalidades para poder hacer pruebas. Lo primero que como buen friki programador pensé fue la posibilidad de conseguir en Internet alguna lista de nombres y apellidos (busqué sobre heráldica, censos electorales y otras cosas así en Google) y luego hacer un programa para generarlos aleatoriamente combinándolos.

El caso es que llegué hasta algo mucho mejor. Se trata de un par de páginas realmente interesantes que permiten generar datos aleatorios con bastantes parámetros.

La primera de ellas es Generatedata.com:

Te permite crear una lista de registros de datospersonales simulados a elegir entre mútliples opciones (ver desplegable de la figura), y luego exportarlos a diversos formatos, incluyendo sentencias INSERT de SQL para meterlos en una base de datos. Lo malo es que sólo soporta datos de ciudades y provincias de los países que se ven en la figura (Canadá, Holanda, EEUU y Reino Unido), pero puede servirnos para muchos casos. La versión gratuita, sin registrarnos, permite generar hasta 200 registros de una vez. "Donando" 20 dólares (unos 14 euros) podemos generar 5.000 de golpe.

La segunda página ya es un poco más peligrosa y puede que roce incluso la ilegalidad, así que la pongo aquí con pinzas ;-)

Se trata de Fake Name Generator:

Esto es ya "la caña". Permite elegir el género, la tipología de nombres (latinos, daneses, americanos, chinos, húngaros, eslovenos y así hasta 14 tipologías) y el país para las direcciones (a elegir entre 19 países). A partir de esto genera una ficha detalladísima de datos personales que incluye hasta número de Visa (falso, claro), número de seguridad social americano (en caso de USA), dirección de e-mail que podremos usar para recibir correo real en ella y hacernos pasar por el individuo en cuestión, o número de tracking de paquetes de UPS!!! Impresionante.

Mira lo que me generó al elegir el nombre latino de una mujer en España:

---
Olaya Nieto Mascarenas
Salzillo, 35
32570 Maside

Email Address: OlayaNietoMascarenas@fontdrift.com

Birthday: November 12, 1951

Visa: 4539 5050 6021 8799
Expires: 12/2011

UPS Tracking Number: 1Z 648 597 13 1249 330 9
---

¡Maside es un pueblo pequeño de la provincia de Ourense, no muy conocido fuera de ahí! Dudo que la calle exista allí, pero el código postal está bien y pertenece al municipio. Es tan fácil y tan preciso que casi da miedo.

Podemos ir generando así, uno a uno, o como es lógico, solicitar un número grande de datos falsos con los campos que nos interesen que podemos bajar en muchos formatos. En este caso tenemos dos opciones según la prisa que tengamos: pagar y que nos los genere de inmediato u obtenerlos gratis esperando a la cola con los demás que también lo hayan solicitado. en ese caso nos dice además el tiempo aproximado que deberemos esperar (por ejemplo, hace un momento eran unos 20 minutos solamente, pero dependiendo de la cola que haya pueden ser varias horas).

Espero que os sirva para hacer el bien ;-)

Bueno, he estado completamente "missing" durante 5 semanas. No es que me haya ido de vacacione (ojalá) sino que simplemente he tenido demasiado trabajo :-(

Retomo mi actividad blogera habitual con una cosa curiosa que me ha pasado recientemente y que estoy seguro de que a más de uno le podrá resultar útil.

Resulta que recientemente migramos una base de datos hecha con SQL Server 2000 a SQL Server 2005. Lo primero que hice una vez adjuntada al nuevo servidor fue poner el modo de compatibilidad con SQL Server 2005, es decir, hacer que se comportara nativamente como si siempre hubiera estado en esta última versión del SGBDR:

sp_dbcmptlevel 'MiBaseDatos', '90'

Este comando T-SQL hace que la BD indicada se comporte con el nivel de compatibilidad indicado, en este caso la versión 9.0 de SQL Server, o sea, la 2005.

El caso es que todo parecía ir estupendamente, pero una de las consultas empezó a fallar. Y se tratata de una consulta muy sencilla. No la voy aponer aquí porque forma parte del dominio de aplicación, pero para que nos entendamos la consulta era básicamente como esta:

SELECT Distinct Tabla1.campo1, COUNT(SR.ID) AS Total
FROM Tabla1
RIGHT JOIN Tabla2 SR ON Tabla1.ID = SR.ID
WHERE --Condiciones
GROUP BY tabla1.Campo1
ORDER BY SR.Total DESC

A la tabla2  le ponemos un alias 'SR' (en la consulta real tenía más sentido).

Bueno, el caso es que, de repente empezó a fallar con un error muy raro que decía algo sobre la ordenación, cuando la consult ano tiene absolutamente nada.

El asunto es que, si ponemos de nuevo la BD en modo de compatibilidad con SQL Server 2000:

sp_dbcmptlevel 'MiBaseDatos', '80'

De repente vuelve a funcionar sin problemas.

El problema viene porque SQL Server 2005 no permite prefijos en las cláusulas ORDER BY porque no permite que haya ambigüedad alguna en esos campos, y por lo tanto asume que no necesitas usar prefijo alguno. Total, que si no tenemos ambigüedades (todos nuestros campos del resultado son de nombres diferentes) entonces podemos poner la consulta sin el prefijo y todo funcionará sin problemas:

SELECT Distinct Tabla1.campo1, COUNT(SR.ID) AS Total
FROM Tabla1
RIGHT JOIN Tabla2 SR ON Tabla1.ID = SR.ID
WHERE --Condiciones
GROUP BY tabla1.Campo1
ORDER BY Total DESC

Es decir, al no haber ambigüedades funcionará en ambas versiones sin problemas. En la 2000 porque no hay ambigüedad y en la 2005 por el mismo motivo (no hay prefijo).

Total que es la típica cosa que te puede volver loco por una tontería si no lo ves enseguida como me pasó a mi :-(

En este artículo de Technet explican má diferencias de compatibilidad entre ambas versiones: http://technet.microsoft.com/en-us/library/ms178653.aspx

Espero que le sirva a alguien. En breve más :-)