jueves, 28 de julio de 2011

Eliminar duplicados en SQL SERVER

Para eliminar filas duplicadas en SQL SERVER, podemos seguir estos pasos:

  1. Crear una tabla que contenga las columnas clave y la cantidad de registros
    duplicados.

  2. Crear una tabla que contenga las filas distintas sin repetir

  3. Eliminar la totalidad de filas duplicadas de la tabla original

  4. Insertar las filas distintas de la tabla creada

Comenzemos creando una tabla e insertandole registros:



CREATE TABLE Prueba
(
Folio int,
Descripcion varchar(50)
)

INSERT INTO Prueba VALUES
(1,'Prueba'),(1,'Prueba'),(1,'Prueba'),
(2,'Otra prueba'),(3,'Otra prueba mas'),
(4,'Otra prueba x'),(5,'Otra prueba y')


Si seleccionamos todas la filas de la tabla mediante: SELECT * FROM Prueba
Obtenemos:

Folio Descripcion
----------- ------------------------------
1 Prueba
1 Prueba
1 Prueba
2 Otra prueba
3 Otra prueba mas
4 Otra prueba x
5 Otra prueba y

(7 row(s) affected)

Son tres filas las repetidas. Vamos a insertarlas en una tabla temporal, agrupadas por la clave, que en este caso es la columna "Folio" (Este ejemplo es sencillo y se utiliza una sola columna, pero pueden ser N columnas, dependiendo de cada caso)

SELECT Folio, COUNT(*) Cant
INTO #TempK
FROM Prueba
GROUP BY Folio
HAVING COUNT(*) > 1


Si seleccionamos las filas de la tabla temporal #TempK obtenemos:

Folio Cant
----------- -----------
1 3
(1 row(s) affected)

Ahora proseguimos a realizar una instrucción "SELECT DISTINCT INTO" para crear
una tabla con las filas distintas, sin duplicados:

SELECT DISTINCT P.Folio, P.Descripcion
INTO #TempC
FROM Prueba P, #TempK T
WHERE P.Folio = T.Folio


Si seleccionamos todas las filas en #TempC tenemos:

Folio Descripcion
----------- ------------------------------
1 Prueba
(1 row(s) affected)

Ya tenemos las filas sin duplicados. Ahora bien, procedemos a eliminar las filas
duplicadas en la tabla original:

DELETE Prueba
FROM Prueba P, #TempK T
WHERE P.Folio = T.Folio


Y ha insertar las filas distintas, sin duplicar:

INSERT Prueba
SELECT *
FROM #TempC


Ahora, seleccionamos todas las filas de la columna original:

SELECT * FROM Prueba


Y tenemos:

Folio Descripcion
----------- ------------------------------
1 Prueba
2 Otra prueba
3 Otra prueba mas
4 Otra prueba x
5 Otra prueba y
(5 row(s) affected)

La tabla sin duplicados. ¿Simple no?

SELECT INTO

SQL Server nos permite ingresar registros a una tabla directamente desde una consulta SELECT, para ello echamos mano de la instrucción "SELECT ... INTO". La sintaxis es:

SELECT {Col1, Col2, ...}

INTO {Tabla Destino}

FROM {Tabla(s) Origen}

[WHERE] {Col1 = val1, Col2 = val2, ...}

[GROUP BY] {Col1, Col2, ...}

[ORDER BY] {Col1, Col2, ...}

Ejemplo:

Sea TABLE1 T1 una tabla, y Col1 y Col2 Columnas de la tabla

SELECT T1.Col1, T1.Col2

INTO T2

FROM TABLE1 T1

WHERE T1.Col1 > 0

Cómo podemos observar, sencillamente se agrega la instrucción "INTO " después de "SELECT" y antes de "FROM", y funciona para toda consulta, con la restricción de que todas las columnas en la selección deben tener un nombre, por ejemplo, si efectuamos una consulta con una función de agregado (SUM, COUNT, MIN, ETC), la columna que tiene la funcón de agregado debe estar identificada por un "alias".

"SELECT INTO" puede utilizarse para crear tablas estandar y temporales. SQL SERVER crea la tabla destino automáticamente, esta no puede existir previamente, por lo tanto No puede ser utilizada con variables tipo Table.

miércoles, 27 de julio de 2011

INSERT EXEC en SQL Server

Para insertar el resultado de un procedimiento almacenado que consulta una tabla en otra tabla, echamos mano de la instruccion INSERT y la instrucción EXEC, de la siguiente manera:

  1. Debemos conocer el resultado del procedimiento almacenado.
  2. Crearemos una tabla (permanete, temporal o variable, según nuestras necesidades y objetivos).
  3. Insertaremos el resultado.

Por ejemplo: sp_tables nos regresa el listado de tablas de la base de datos actual y su estructura es:
  • TABLE_QUALIFIER
  • TABLE_OWNER
  • TABLE_NAME
  • TABLE_TYPE
  • REMARKS

Crearemos una tabla temporal para insertar el resultado

CREATE TABLE #Temp
(
TABLE_QUALIFIER varchar(50),
TABLE_OWNER varchar(50),
TABLE_NAME varchar(50),
TABLE_TYPE varchar(50),
REMARKS varchar(250)
)

Insertaremos directamente el resultado del procedimiento almacenado:

INSERT #Temp EXEC sp_tables

Y listo, podemos utilizar la tabla obtenida del procedimiento almacenado.

SELECT * FROM #Temp

¿Sencillo verdad?

lunes, 25 de julio de 2011

Moprosoft: Registro de proyecto

Seguirmos con la gestión de proyectos. La siguiente parte deberá ser más familiar, ya que tiene que ver con el control del proyecto, no con las ventas.

Pues bien, el control del proyecto no es más que darle correcto seguimiento, de principio a fin. Comenzamos con el registro del proyecto, pasamos por su descripción, le asignamos recursos, definimos metas, le damos seguimiento y monitoreo y lo cerramos.

Esto es importantísimo: Debemos enfocarnos en cumplir con el proyecto, en cumplir con los requerimientos en tiempo y forma y sobre todo cerrar el proyecto.

El proyecto se cierra mediante la firma de un documento de aceptación por parte del(os) cliente(s), es decir, se da formalización a que el proyecto ha concluido satisfactoriamente.

Pues muy bien, el artefacto con el que iniciamos es escencial una buena base de datos de proyectos, que es un listado completo de los mismos, con datos relevantes tales como:
  1. Cliente (al que pertenece el proyecto)
  2. Nombre del proyecto
  3. Estatus
  4. Porcentaje de Avance
  5. Fecha de inicio
  6. Fecha de finalización
  7. Responsable del proyecto
  8. Precio del proyecto
Este documento, esta base de datos, Moprosoft la llama Registro de Proyectos. Como podemos observar, este artefacto es básico, muy básico para la administración de proyectos de software, prácticamente mandatorio para toda empresa de desarrollo de software (si no cuentan con el ¡¿Que esperan?¡).

Su objetivo y función es simple: Registrar y llevar control de los proyectos. Existen muchos datos con los que podemos complementar este artefacto (costo, cantidad de horas, recursos asignados, etc), sin embargo, estos son los mandatorios por la norma, por lo que mínimamente debes contar con ellos.

Moprosoft: Descripción del proyecto

La descripcíon del proyecto es un artefacto importante que "sigue" todo el camino del proyecto. En este se establecerá el alcance del mismo, pero mejor veamos cual su contenido:

Necesidad del negocio
¿Que necesidad tienen los clientes que el proyecto debe satisfacer? Una breve fundamentación del por que es necesario el negocio, o que necesidad especifica provee la implementación del proyecto. Un enfoque para redactarlo directamente es ¿Qué necesita el cliente?

Propósito
El propósito del proyecto es la razón de su existencia ¿Para qué desarrollamos este proyecto? ó ¿Cuál es su función principal?

Objetivos
Aqui se listan los objetivos específicos del proyecto, ¿con que deberá cumplir el proyecto para considerarse terminado?

Alcance
Basado en los objetivos del proyecto, en esta sección se dividen los límites del proyecto, que abarca, que no, que actividades se realizarán, que actividades no se realizarán. Es muy importante llevar a cabo una correcta redacción del alcance en los proyecto.

Supuestos y premisas
Aqui se listan los compromisos del cliente que damos por hecho para llevar a cabo el proyecto, tales como: Acceso a la información, que cuente con los recursos necesarios, etc.

Restricciones
En general, cualquier factor restrictivo dentro del proyecto debe especificarse en este apartado. Algunos ejemplos son: Tiempo, lenguaje de programación a utilizar, frameworks y tecnologías, permisos y accesos a los recursos de sistema como bases de datos, aspectos legales, etc.

Productos
Aqui se describe el producto que te estan comprando, en español plano, según lo que hayas acordado con el cliente, en breve: Que estas vendiendo o que te estan comprando.

Entregables
Los entregables son los productos de software que le debes entregar al cliente, ya sean documentos como manuales, aplicaciones, instalables o producto ya instalado. Deben ser medibles o cuantificables y es extremadamente importante listarlos, ya que nos basaremos en ellos para firmar la entrega del proyecto.

Responsable de la Administración Específica del Proyecto
Por regla, todo proyecto debe tener un responsable y se le debe dar formalidad a dicha responsabilidad.

Comunicación con el cliente
Aqui estableceremos el protocolo a seguir, que se documentará y que medios o características tienen validez dentro del proyecto para contar como seguirmiento del mismo. Por ejemplo, si el proyecto es a larga distancia, puede determinar que toda la comunicación se lleve por correo electrónico, o mediante un sistema especializado de seguimiento, etc.

jueves, 21 de julio de 2011

Moprosoft - Referencias

Referencia de entradas de Moprosoft

  1. ¿Que es el Moprosoft? Enlace
  2. Por donde comenzar Enlace
  3. Implementación de Moprosoft Enlace
  4. Gestión de Proyectos Enlace
  5. Plan de ventas Enlace
  6. Registro del proyecto Enlace
  7. Descripción del proyecto Enlace

Plan de Ventas - Gestión de proyectos - Moprosoft

El plan de ventas consta de:
  • Identificar prospectos (posibles clientes)
  • Generar propuestas (en conjunto con los desarrolladores y analistas, ya que requerimos estimar tiempos y costos)
  • Presentar propuestas a los prospectos.
  • Darles seguimiento.
  • Cerrar las propuestas mediante la firma de contratos.
Por lo tanto, debemos llevar un control total de las ventas, comenzando por su planeación.
Plan de Ventas
Basandonos en las cuatro P's de la mercadotecnia tenemos:
  • Producto
  • Precio
  • Promoción
  • Plaza
  • Y le agregamos cantidad.

Producto: Nuestro producto son los desarrollos de software. Tenemos que categorizarlos, si ya tenemos software desarrollado que vendemos pre-fabricado y solamente le hacemos ajustes al gusto del cliente, ya estamos del otro lado, ¡esa es la categoría! Sino, pues debemos categorizar nuestros desarrollos, por mercado meta, por giro de negocios de nuestros posibles clientes, por cualquier estrato que sea importante para nosotros.

Todo producto tiene que tener un Precio. Si ya tenemos el software prefabricado y ya tenemos el precio, que mejor. Pero si no debemos contar con una política de precio basada en factores medibles o cualitativos. Una estrategia muy socorrida es la tarifa por horas. La política de precios debe quedar asentada.

La promoción es la manera en cómo vamos a vender. Aqui entran tanto las R.P. como las estrategias de marketing. ¿Cómo voy a promocionar mi producto - mis servicios como desarrolladora de software -? Mediante mi sitio web, implementando un shopcart, google AdWords, llendo a convenciones, elaborando una carta de ventas, contratando a una agencia de mercadotecnia, etc.

La plaza es ¿en dónde los vamos a vender? No solamente especificado local, sino el sector, el nicho o división de mercado, el web, el del cliente directo, será local, nivel nacional o producto de importación, ¿que sector geográfico ocupa mi mercado meta?

La cantidad es el número meta que tengo que vender del producto o tipo de servicio en cuestión. Es el número más importante ¿Cuanto tengo que vender?

Es importantisimo proyectar, documentar y fomentar la revisión a todos estos puntos.

Seguimos con el control de las ventas, debemos llevar un registro de Seguimiento a Prospectos. Tenemos que registrar cada llamada que nos hagan, cada mail que nos llegue solicitando información o costo. Es importantísimo llevan una bitácora que incluya:
  1. Prospecto (nuestro futuro cliente)
  2. Producto (o tipo o servicio)
  3. Fecha
  4. Bitácora (registro de los acontecimientos, "me llamó", "me llegó correo", "le devolví llamada", "se mostró interesado", etc)

Es vital llevar una agenda, una Planeación de Eventos. Esta debe tener como mínimo la siguiente estructura:
  1. Producto o tipo de servicio
  2. Evento (convención, junta, presentación, etc)
  3. Fecha
  4. Registro de prospectos (Quienes se mostrararón interesados o asistieron o convocaron a la junta)

Otro documento importante y subsecuente es el Cierre de Oportunidades. Aqui ya el prospecto mostró interes, ya solicitó cotización formal y nos determinamos a culminar la venta. Llevamos un registro de avance, en porcentaje y con bitácora sobre el comportamiento del cliente. los datos que debe contener este artefacto son:
  1. Oportunidad (que proyecto vamos a vender)
  2. Prospecto (nuestro futuro cliente)
  3. Probabilidad de ventas (en porcentaje)
  4. Fecha
  5. Bitacora (comentarios pertinentes o resumen de minutas de juntas para conocer el avance de la venta en detalle)

Moprosoft - Gestión de proyectos

La gestión de proyectos es la parte en Moprosoft que une a la administración con la producción. Es la encargada de gestionar que la parte operativa haga su trabajo, así como reportar a la administración y monitorear la correcta provisión de recursos.
Es recomendable proceder inmediatamente con ella después de revisar la Gestión de Negocios.

La gesitión de proyectos trata con los clientes, es el proceso encargado de buscar el trabajo, firmar los contratos y los documentos de aceptación en la terminación de los proyectos.

Podemos
dividir a la gestión de proyectos en tres áreas principales:
  1. Ventas
  2. Proyectos
  3. Clientes
Debes realizar seguimiento y labor de ventas, registro y monitoreo de proyectos y tratar con los clientes (si, incluyendo las firmas, los acuerdos, cambios en el proyecto y las quejas).

Esta información debe quedar plasmada en el Plan de Ventas.

Implementación de Moprosoft

La documentacíon formal pueden encontrarla gratuitamente en la sección de descargas de Comunidad Moprosoft, o en la norma de NYCE. En este apartado nos dedicamos a comentar la forma en que recomendamos abordar el tema de la implementación.

Moprosoft se trata de documentar todo. Con base en nuestra experiencia, los evaluadores se dividen en dos: Los asesores de otras empresas de software y los evaluadores oficiales de NYCE.

Los asesores pueden ser mucho más quisquillosos, ya que los resultados de su trabajo se miden con que los empresas asesoradas aprueben los niveles de software, no obstante, no se basan enteramente en la norma desde un enfoque práctico, sino más arbitrario y basandose en cumplir con la documentación antes de encontrarle una utilidad verdadera, lo cual es un completo error, una falacia, ya que el objetivo de Moprosoft es que las empresas realicen mejor software.

Los evaluadores reales, aunque tampoco miden que deverdad hagas mejor software y se basan enteramente en la norma (que los artefactos esten todos, se llamen como deban llamarse y que contengan los datos mínimos necesarios, con sus nombres oficiales) no son tan quisquillosos (al menos en los primeros niveles) con el control de versiones, ya que la norma no lo especifica. En resumen, debes de tener el artefacto, nombrado oficialmente y sus datos mínimos, nombrados oficialmente y lo más importante: ¡Debes usarlo! Esa es la mejor manera de aprobar niveles en Moprosoft, sacandole jugo de verdad.

Cómo en todos los procesos administrativos, podemos dividirlos (y Moprosoft lo hace con todos los procesos) en Planeación, Realización y Evaluación y control. Otro punto importante a destacar es que comúnmente a todos los documentos se les llama "artefactos".

Con estos conceptos en mente, comencemos pues, con diversas entradas involucrándonos en temas específicos, en la categoría de Moprosoft o en esta entrada de Referencias.

miércoles, 20 de julio de 2011

Alternativa a SQL Agent

Es bastante común en las versiones Express de SQL Server que se busque una alternativa a SQL Server Agent para programar JOBS tan necesarios como actualizar algunas tablas o crear respaldos.

La alternativa es similar a lo que se hace con MYSQL, usando la herramienta OSQL para efectuar los comandos y creando una Tarea Programada en Windows.

El proceso consta de tres sencillos pasos:
1) Crear un archivo *.sql con las instrucciones deseadas (actualizaciones, respaldos, restauraciones, etc)
2) Crear un archivo *.bat que ejecute OSQL llamando al scritp *.sql creado.
3) Crear una tarea programada en Windows que ejecute el archivo *.bat (ó *.cmd).

Ejemplo:
Supongamos que deseamos respaldar una base de datos.
Abrimos el bloc de notas (o el Notepad++ ó Sql Server Management Studio ó el editor SQL que usen) y tecleamos:

USE Master
GO
BACKUP DATABASE [MiBaseDeDatos] TO DISK = N'C:\MisRespaldos\MiBaseDeDatos.BAK' WITH INIT;
GO

Guardamos el archivo ("Miscript.sql", por ejemplo).
Volvemos a abrir el editor y tecleamos:

OSQL -E -i C:\Ruta_A_Mi_archivo\Miscript.sql -o C:\Ruta_Deseada\Salida.rpt -n

Guardamos el archivo como "RespaldoMiBase.bat".
Creamos la tarea programada en Windows, configurandola para ejecute el archivo: "RespaldoMiBase.bat"
Y listo.

El parámetro -E en OSQL significa que se usa una conexión de confianza. Si deseas configurar usuario y contraseña debes usuar los parámetros adecuados:
-U [Nombre de Usuario o Login] y -P [Contraseña]
El parámetro -n significa "no headers", con ello los encabezados (carácteres < y > y conteo de lineas) no se escribirán.
El parámetro -o significa archivo de salida. Especificando el archivo de salida provocará que lo resultados se impriman a este, pero no a pantalla.
Si utilizas una conexión de confianza no se te olvide incluir "USE [DATABASE]" o referir con ruta completa (BaseDeDatos.schema.Tabla) a las tablas de las base de datos.

No se les olvide probar antes el script SQL, la llamada a OSQL desde la línea de comandos y por último la ejecución del archivo *.bat.

Además, deben recordar que las tareas programadas en Windows dependen de la cuenta de usuario que les asignan, asi que si cambian la contraseña y no actualizan la tarea, esta no se ejecutará.

Como redactar manuales de usuario

Lo principal que se debe tener en cuenta al desarrollar un manual de usuario es: Escribirlo para que lo entienda hasta un niño de 6 años. Si, prácticamente escribirlo "For Dummies".
Y no se trata de menospreciar a los usuarios, pero al aprender algo nuevo, TODOS somos "dummies".

El manual de usuario es muy importante, casi tanto como lo es la aplicación misma y al redactarlo debemos ponernos en los zapatos de los usuarios "newbies", que no conocen ni pizca del sistema, como si no supieramos ni abrir la aplicación.

El manual de usuario debe estar estructurado y detallado. La forma más sencilla es dividirlo por módulos (tal y como la aplicación) y ordenarlo por funciones (primero debes dar de alta un cliente para poder consultarlo y luego modificarlo, etc).

Otro punto clave es el lenguaje: Este debe ser claro, conciso y natural, nada de palabras de programación ni complicadas, mucho menos rimbombantes. Se debe "hablar natural", como si le explicaras a un sobrino pequeño pero con cariño, nunca con condescendencia.

Se deben combinar tanto la narrativa como la esquematización y sobre todo las imágenes. Cuantimás imagenes descriptivas y adecuadas al caso implementemos, mejor. Claro que estas deben estar referenciadas y con una nota al pie.

El proceso puede ser arduo y fatigoso, pero trae grandes recompensas, un manual de usuario bien escrito y que sirva de referencia te puede ahorrar horas de capacitación.

Nos debemos asegurar que se explique como funciona el sistema, que datos se deben capturar (entradas), una breve descripción de lo que hace el sistema (proceso) y los datos que arroja (salida), todo en un lenguaje natural y fluido, sin meternos en detalles.

No nos olvidemos de los errores (para un usuario, cualquier ventana de advertencia es un "error del sistema", también cualquier comportamiento no esperado). Debemos especificar una sección especial para tratar "En caso de error...".

Todo es muy importante, pero ¿cómo comenzar? Un buen comienzo es listar las funciones del sistema. Luego ordenarlas cronológicamente, según el usuario las tenga que utilizar en el sistema.
Posteriormente describirmos cada función brevemente y detallamos las entradas, y salidas, especificando las verificaciones y validaciones pertinentes.
Para las entradas, salidas y verificaciones es recomendable apoyarnos con viñetas.

Una vez efectuados estos pasos, seguiremos complementandolos con imágenes, con sus referencias y notas al pie de lo que se traten. Luego, si es necesario, con un sencillo editor de imágenes (presente en cualquier ofimática) podemos manipular las imágenes para resaltar funciones, íconos y botones necesarios.

Una vez que tengamos este avance todo es mucho más sencillo, nos proponemos revisar el orden, efectuar correcciones necesarias, etc.

El manual debe servir de referencia, por lo que un buen indice es escencial. Además, incluir un "FAQ" y una sección (o el manual entero!) a modo de "Como hacer para...".

Pues bien, por último solo me queda recordar que nunca se nos debe olvidar la perspectiva: Debemos escribirlo para las personas que los van utilizar muy seguido y que no tienen conocimientos avanzados, no para otro desarrollador o para uno mismo.

martes, 19 de julio de 2011

Cotización de un proyecto

¿Cuantas veces no nos hemos roto la cabeza cotizando? Cotizar es una de los problemas más comunes para los ingenieros de software ¿Cuánto voy a cobrar? es una pregunta muy popular.

Existen varias respuestas, varios enfoques, pero primordialmente se debe conocer:
  • Cuanto te cuesta operar
  • Cuanto quieres ganar
El primer paso es obtener un costeo de la operación, es decir ¿cuanto te cuesta trabajar, producir software?
La forma más sencilla de responder esta pregunta es elaborando toda una lista de gastos:
  • La nómina
  • La renta
  • Los servicios
  • Los impuestos
  • Los consumibles
  • La gasolina
  • Etc.
Elaborando esta por periodo mensual y prorrateando la sumatorio entre el total de horas trabajadas te puede dar un costo promedio total por hora. Esta dato es importante, ya que, aunque no te guste cobrar por hora, multiplicado por el total de horas que durará un proyecto obtienes la cantidad mínima que debes obtener de ingresos para no tener pérdida. No puedes cobrar menos que eso, o perderás dinero.

No obstante nadie quiere perder, todos queremos ganar, por lo tanto, al costo total de cada proyecto le agregamos un porcentaje de utilidad, que puede variar según varios factores como el poder adquisitivo del cliente, o si va a ser financiado o los periodos de pago diferidos, etc. Aqui entra el factor de cuanto quieres ganar.

Claro, calcular el tiempo total que tomará efectuar un proyecto es otro problema aparte, bastante común. Para ello se puede echar mano de varias herramientas avanzadas de la ingeniería de software, pero el punto principal es que se debe tener una métrica de cuanto tiempo toma hacer determinada cosa, producto por producto, función por función (cuanto te toma escribir una tabla, vista o procedimiento almacenado en SQL, cuanto de toma crear un formulario en web, cuanto en windows, en diversos lenguajes, etc).

Se deben proyectar todas y cada una de las actividades y tener sus tiempos o costos de operación predefinidos. Realmente, construir software no es muy diferente de construir una casa, los arquitectos manejan los que llamas "tarjetas" con métricas predefinidas de costos, así que los arquitectos de software también deben tenerlas. Si no cuentas con herramientas avanzadas o software especializado para ello, una lista en cualquier programa de hoja de cálculo te puede servir, o puedes crear tu propia base de datos, proyecto interno que te dejará muchos rendimientos a largo plazo.

viernes, 1 de julio de 2011

Resolver conflicto de intercalación en SQL Server


En ocasiones tenemos que efectuar consultas JOIN o referenciadas entre tablas y cuando estas tienen diferentes intercalaciones (COLLATIONS), SQL Server nos arrojará un error del tipo "Cannot resolve the collation conflict between..." o "No se puede resolver el conflicto de intercalación entre...".
Pues bien, existe una manera sencilla de superar esta dificultad sin tener que utilizar comandos ALTER para cambiar la intercalación de alguna de las columnas, utilizando la sentencia COLLATE DATABASE_DEFAULT.
Ejemplo, en un escenario como el siguiente, en que se tengan dos o más tablas con diferentes intercalaciones en alguna de sus columnas:
CREATE TABLE Tabla1
(
Id int not null,
Descripcion varchar(50) COLLATE Latin1_General_CS_AS not null
)
GO

CREATE
TABLE Tabla2

(
Id int not null,
Descripcion varchar(50) COLLATE Modern_Spanish_CI_AI not null
)
GO
-- INSERTANDO VALORES DE PRUEBA
INSERT INTO Tabla1 VALUES (1,'Descripcion 1')
INSERT INTO Tabla1 VALUES (2,'Descripcion 2')
GO
INSERT INTO Tabla2 VALUES (1,'Descripcion 1')
INSERT INTO Tabla2 VALUES (2,'Descripcion 2')
GO

Ahora, si intentamos efectuar un JOIN o una consulta de comparación (ejemplo con la claúsula "IN"), SQL nos marcará un error.

SELECT T1.*
FROM Tabla1 T1
INNER JOIN Tabla2 T2
ON T1.Descripcion = T2.Descripcion
--ó
SELECT *
FROM Tabla1
WHERE Descripcion IN ( SELECT Descripcion FROM Tabla2 )

Nos muestra el error: 'Cannot resolve the collation conflict between "Modern_Spanish_CI_AI" and "Latin1_General_CS_AS" in the equal to operation.'
Ahora, utilzando de la siguiente manera la sentencia "COLLATE DATABASE_DEFAULT"

SELECT T1.*
FROM Tabla1 T1
INNER JOIN Tabla2 T2
ON T1.Descripcion COLLATE DATABASE_DEFAULT = T2.Descripcion COLLATE DATABASE_DEFAULT
-- Ó
SELECT *
FROM Tabla1
WHERE Descripcion COLLATE DATABASE_DEFAULT
IN ( SELECT Descripcion COLLATE DATABASE_DEFAULT FROM Tabla2 )

Nos arroja un resultado sin errores:
Id Descripcion
----------- --------------------------------------------------
1 Descripcion 1
2 Descripcion 2

(2 row(s) affected)