martes, 7 de agosto de 2007

It is not possible to run two different versions of ASP.NET in the same IIS process

Inmediatamente intentaba de entrar a una aplicacion Asp.Net me indicaba un mensaje de error que me decia "Server Application Unavailable", la cual no me especificaba absolutamente nada de que podria ser el origel del problema.

Como todo buen programador, cuando ocurre un fallo en alguna de las aplicaciones ya en produccion y el error mostrado no especifica absolutamente nada que nos pueda pueda ayudar, debemos de pensar en cual fue el ultimo cambio realizado, ya que ha sido una aplicacion que siempre a funcionado. Recorde que al servidor web le habia instalado recientemente el MS Framework 2.0 para una nueva aplicacion. Verifique el event viewer y efectivamente alli esta el problema:

"It is not possible to run two different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process."

La solucion es relativamente sencilla, cuando se tienen aplicaciones corriendo con diferentes versiones de framework en un mismo servidor web, es necesario crear un applicacion pools para cada version de framework e indicarles a cada aplicacion cual application pools usar en las propiedades de la aplicacion desde el IIS.

Restaurar base de datos a partir de un MDF

Nueva situacion:

Varias base de datos estaban utilizando varios filegroup para almacenar los indices, dichos filegroups estaban ubicados en discos diferentes al MDF, y el archivo de log de transacciones de todas las bases de datos tambien estaban en discos diferentes.

Resulta ser que el disco que contenia los filegroups y los log de transacciones se perdio, unicamente quedaron los MDF solos y no existian backups.

Cuando trataba de hacer un simple attach a las base de datos, el servidor SQL Server 2005 buscaba los archivos asociados a el (los filegroups y logs) en las mismas ubicaciones que estaban (ubicaciones y archivos que ya no existian) y al no encontrar nada no me dejaba atacharlas.

Mi razonamiento era el siguiente: en los filegroups (.NDF) solo estaba almacenando los indices, los log de transacciones se reconstruyen cuando estos se pierden o se corrompen. Y lo que me quedaba en las manos eran los MDF que son los que contienen la data real, los registros y las tablas, pues teoricamente tenia en mis manos lo que realmente importaba.

El hecho es que intente todo y nada fue posible, pase varios dias buscando informacion en el MSDN, en foros sobre el tema... y no hay solucion cuando se pierden los filegroup asociados a la DB, aunque no lo utilices y no contengan nada.

En resumen, NUNCA TE DESCUIDES CON LOS BACKUP, es la unica garantia segura con SQL Server de recuperar informacion, olvidate de que tienes el log de transacciones, el MDF, porque nada es seguro.

viernes, 3 de agosto de 2007

Encriptar clave en SQL Server 2005

Buscando el google encontre varias opciones para encriptar un campo, pero el que me resulto mas facil y comodo de usar fue la funcion pwdencryp(campo), devuelve una cadena encryptada.

Lo que deseaba hacer era encriptar todas las claves de la tabla de usuarios de un sistema que trabajo habitualmente, aqui doy los pasos para lograr tal objetivo:

1. Lo primero es cambiarle el tipo de dato al campo de la clave de varchar(longitud) a varbinary(256), pero antes de esto, tenemos que guardar nuestras claves viejas sin encriptar en un campo temporal para no perder la informacion de la claves de los usuarios.

Cree un campo tiempo llamado "temp", luego pasamos las claves sin encriptar a dicho campo:

alter table usuarios add temp varchar(20)
go
update usuarios set temp = clave
go

2. Cambiar el tipo de dato al campo clave

alter table usuarios alter column clave varbinary(256)

3. Pasando las claves encriptadas a nuestro campo y eliminando el campo temporal

update usuarios set clave = pwdencryp(temp)
go
alter table usuarios drop column temp
go

4. Validando nuestro usuario por medio de una consulta

select * from usuarios where login = @login and pwdcompare(@clave, clave, 0) = 1

si no devuelve ningun registro es porque el usuario o la clave son incorrectas.