Change collation for SQL 2008 Instance

Change collation for SQL 2008 Instance

In order to change the Default Engine Collation in SQL Server 2008 you will need to stop the (ALL) MSSQL Server instance(s) and execute the following command from the SQL Server setup media:

setup.exe /q /ACTION=RebuildDatabase /INSTANCENAME=MSSQLSERVER /SAPWD="" /SQLSYSADMINACCOUNTS="BUILTIN\ADMINISTRATORS" /SqlCollation=Latin1_General_CI_AI
Bear in mind that by using the above command you are to all intents erasing and recreating your SQL Servers MASTER database, you will invalidate an previous MASTER backups (as they will contain the previous Collation Settings) and the major knock on effect is that your Current Login and Security configuration will also disappear couple that with the fact your existing Databases will be detached from the server. There are other issues such as backup stats being lost – so be VERY careful when using the above command.

Error changing collation

Error changing collation

If you try to change Collation in database and you get some error like this,

Msg 5030, Level 16, State 2, Line 1
The database could not be exclusively locked to perform the operation.
Msg 5072, Level 16, State 1, Line 1
ALTER DATABASE failed. The default collation of database 'BI_CONVERTION' cannot be set to Latin1_General_CI_AI.

Try this solution:
You need to get the database to single-user mode. You may need to go through and kill all of the current sessions so that you can get it to single user mode. Once you do, you essentially have an exclusive lock on the database. At that point, you shoudln't haven't a problem changing the collation.

Another way to make it:

To alter the database state to restrict the access to the single user mode, first open the Microsoft SQL Server Management Studio, and connect to a SQL Server instance. Open the list of available databases belonging to the related instance in the Object Explorer window. Right click on the sql server database that you want to set its mode to single user and select Properties in the context menu.

When you click properties menu item, the following Database Properties screen will be displayed for the selected database.

Select the Options page from the list in the left side of the screen. If you scroll down the options list for State options, you will see Restrict Access database options with three options listed in the combo box.

Restrict Access modes : Multiple, Single and Restricted modes.

If you select Single mode and click the OK button, you can either alter the database access mode to single user successfully or you will fail to change the access mode because of existence of active open connections to the Works database. The Management Studio IDE will prompt you to close all other connections to the related database for a successfull alter database option process.

To change the database properties, SQL Server must close all other connections to the database. Are you sure you want to change the properties and close all other connections?

After the alter command runs successfully, the database XXX will be displayed as shown in the Object Explorer window.

If an active connection exists other than the Management Studio, and you click the database XXX within the SQL Server Management Studio, the following warning message will be displayed:

The database XXX is not accessible. (ObjectExplorer)

If you right click on the database XXX, the following error message will be displayed.

Database 'XXX' is already open and can only have one user at a time. (Microsoft SQL Server, Error: 924)

After a database is altered as single user mode, it can be altered again back to multi user mode by running the below sql command.

ALTER DATABASE [XXX] SET MULTI_USER WITH NO_WAIT

TSQL to change collation of database in SQL 2008

TSQL to change collation of database in SQL 2008

This script is wonderful to change all collation columns:

declare @toCollation sysname

SET @toCollation = 'Latin1_General_CI_AI' -- Database default collate

SELECT 'ALTER TABLE ' + INFORMATION_SCHEMA.COLUMNS.TABLE_NAME +
' ALTER COLUMN ' + COLUMN_NAME + ' ' + DATA_TYPE +
CASE WHEN CHARACTER_MAXIMUM_LENGTH = -1 then '(max)'
WHEN DATA_TYPE in ('text','ntext') then ''
WHEN CHARACTER_MAXIMUM_LENGTH IS NOT NULL
THEN '('+(CONVERT(VARCHAR,CHARACTER_MAXIMUM_LENGTH)+')' )
ELSE isnull(CONVERT(VARCHAR,CHARACTER_MAXIMUM_LENGTH),' ') END
+' COLLATE ' + @toCollation+ ' ' + CASE IS_NULLABLE
WHEN 'YES' THEN 'NULL'
WHEN 'No' THEN 'NOT NULL'

END
FROM INFORMATION_SCHEMA.COLUMNS INNER JOIN INFORMATION_SCHEMA.TABLES
ON INFORMATION_SCHEMA.COLUMNS.TABLE_NAME = INFORMATION_SCHEMA.TABLES.TABLE_NAME
AND INFORMATION_SCHEMA.COLUMNS.TABLE_SCHEMA = INFORMATION_SCHEMA.TABLES.TABLE_SCHEMA
WHERE DATA_TYPE IN ('varchar' ,'char','nvarchar','nchar','text','ntext')
AND TABLE_TYPE = 'BASE TABLE'
and COLLATION_NAME <> @toCollation

This print the scripts in console for execute it, Copy the results in console an paste into new query. Execute, and thats all!

7 capítulos que no pueden faltar en plan de administracción de riesgos

7 capítulos que no pueden faltar en plan de administracción de riesgos

¿Para qué sirve un plan de administración de riesgos, no es algo muy formal que se usa solamente en megaproyectos?.

Las respuestas son: sirve para comunicar riesgos a todos los involucrados, no es algo muy formal y no se usa solamente en megaproyectos. Si tu proyecto es pequeño también se puede usar. Es un documento corto de unas dos o tres hojas que debe tener por lo menos estos 7 capítulos:

1. Metodología: este capítulo describe cómo vas a manejar los riesgos en el proyecto. ¿Qué tipo de análisis probabilístico aplicarás para cada factor de riesgo? ¿Vas a contratar consultores? ¿Vas a contratar algún seguro? ¿Vas a analizar otros proyectos en la organización? ¿Vas a analizar algún factor externo que pueda influir en los riesgos del proyecto?

2. Roles y responsabilidades: este capítulo describe quiénes estarán a cargo del plan de administración de riesgos y quiénes serán responsables de ejecutar las respuestas al riesgo si los eventos de riesgo ocurren. Describe también quién es el Dueño del Riesgo para cada factor de riesgo.

3. Presupuesto: describe cuánto cuesta el proceso de administración de riesgo en el proyecto, y cómo se gastará en dinero asignado. El costo podría ser expresado por ejemplo en términos de horas dedicadas. El presupuesto se divide en una parte fija (las estrategias de minimización de riesgos, que se ejecutan siempre) y en un parte variable (las acciones de contingencia, que se ejecutan solamente si el evento ocurrió).

4. Tiempo: describe cómo se combinarán las tareas relacionadas a riesgos con el resto del cronograma del proyecto. Por ejemplo en este capítulo se puede comunicar que las reuniones de análisis de riesgos se realizarán después de las
reuniones de estado del proyecto, todos los viernes.

5. Puntuación: este capítulo describe qué sistema de puntuación se usará para clasificar a los factores de riesgo, y de qué forma se usará la escala de gravedad para reaccionar. Por ejemplo: “Los factores de riesgo se clasificarán en una escala de 1 a 10 por su gravedad. Un riesgo Grave es aquel con puntuación 8 o más”.

6. Tratamiento de riesgos: este capítulo explica qué factores de riesgo serán tratados en primer lugar, ya que la lista puede ser grande y algunos riesgos pueden quedar en monitoreo pero quizás no se traten. Por ejemplo aquí se puede decir: “Los riesgos de gravedad 8 o más que tengan más del 50% de probabilidad de ocurrencia serán tratados en primer lugar”.

7. Reporte de riesgos: este capítulo describe la forma y la frecuencia de reportar los riesgos a patrocinadores y demás involucrados. Por ejemplo: “Cada lunes a la mañana recibirán una planilla electrónica describiendo los cambios en la evaluación cualitativa y cuantitativa de los 10 factores de riesgo más importantes del proyecto”.

Escribe un documento así en el próximo proyecto y vas a ver que te servirá mucho, incluso si no se lo entregas a nadie. Te puede servir para ordenar tus pensamientos con respecto a los riesgos del proyecto y tenerlos en cuenta a lo largo de todo el ciclo de vida.

La pregunta de siempre: ¿Es aplicable? ¿Te ves haciendo esto el lunes a la mañana en tu próximo proyecto?

5 ingredientes para ser un buen gerente de proyectos

5 ingredientes para ser un buen gerente de proyectos

¿Qué se necesita para ser un buen gerente de proyecto? ¿Qué me falta? ¿Tengo que estudiar? ¿Tengo que certificarme como PMP? Estas preguntas son muy frecuentes. ¿Qué se necesita para ser un buen PM? Cuatro cosas: ser, saber, saber hacer, querer hacer. Veamos:

Ser: personalidad.

No olvidar: la personalidad cambia con el tiempo y además, se puede cambiar. Es difícil pero se puede.

Saber: formación. Sí, hay que estudiar. Es bueno certificar porque tu esfuerzo se reconoce en cualquier lugar.

Saber hacer: habilidades. Para adquirirlas hay que practicar, para practicar hay que trabajar y buscar desafíos.

Querer hacer: motivación.

Sentido Común

Cosas que nos hacen perder tiempo en un proyecto

Cosas que nos hacen perder tiempo en un proyecto

Escenario típico: jueves, 20:00 horas. Estás en la oficina, te duele la cabeza, repasas tu lista de tareas que preparaste a la mañana, y apenas completaste dos de las diez que tenías. ¿No tendrás un problema de productividad? Quizás no estés aprovechando tu tiempo como es debido. Veamos algunos fenómenos típicos en una oficina que nos hacen perder el tiempo todo el día, todos los días:

1. “Conócete a ti mismo”: ¿nunca pensaste que quizás la culpa sea tuya? Desperdiciadores de tiempo por culpa tuya, de ningún otro:

* Falta de prioridades o ignorar las prioridades.

* Falta de planes con tareas diarias y semanales.

* Objetivos no claros.

* Dejar cosas para después .

* Intentar hacer muchas cosas a la vez.

* Falta de autodisciplina.

* Confundirse entre “urgente” e “importante”.

2. Uso del teléfono: un gran desperdiciador de tiempo. Algunos consejos:

* Antes de llamar, planificar la conversación.

* Filtrar y agrupar las llamadas por hacer, tratar de apartar un tiempo específico para llamadas.

* Si la conversación se extiende innecesariamente, tratar de acortarla.

* Establecer momentos en el día en donde no se recibirán llamadas.

3. Uso de mensajería instantánea: el rey de las interrupciones. Una de las cosas más irritantes de la mensajería instantánea es que te interrumpe siempre en el lugar en donde estás trabajando (en tu computadora).

* Destinar una cantidad de tiempo al día para el chat.

* Evitar tener abierta la ventana del chat y las herramientas de trabajo al mismo tiempo.

* Utilizar estatus como “No disponible” o “Ausente” la mayor parte del tiempo.

4. Uso de correo electrónico: a veces parece que tu trabajo consiste en escribir y leer correos electrónicos. Para que no sea así:

* Escribir menos, usar más el teléfono si hay algo que se pueda explicar mejor por ese medio.

* Destinar una cantidad de tiempo al día para leer y redactar correos electrónicos,

* Escribir en forma contundente: eliminar palabras, frases y párrafos innecesarios.

* Pensar antes de escribir, planificar lo que queremos expresar.

* Antes de enviar, pensar siempre: “¿A quién más debo copiar en este mensaje?”

5. Visitantes inesperados: el consejo más importante

* Aprender a decir no, especialmente cuando nos preguntan si tenemos un minuto. No queda mal si decimos “ahora no tengo un minuto, pero en un momento te llamo”.

6. Reuniones: hay días en que tu trabajo parece también que consistiera en estar en reuniones. Algunas cosas para tener en cuenta:

* Desalentar las reuniones innecesarias. ¿Quizás se pueda solucionar con una llamada telefónica?

* Fijar un límite de tiempo y ajustarnos a él.

* Preparar la reunión publicando una agenda de antemano y seguirla.

Ocho consejos para mejorar la gestión de los proyectos

Ocho consejos para mejorar la gestión de los proyectos

Éstos podrían se los consejos que le daría a un buen amigo al empezar el liderazgo de proyectos dentro de su carrera profesional:

1. Mantenernos cerca de nuestro cliente: desarrollar un diálogo constante con el cliente para ajustar el rumbo del proyecto todos los días si es necesario. Visualizar los resultados, “comenzar por el final”.

2. Cuidar a nuestro equipo: generalmente pensamos que el cliente está siempre primero. No podemos cuidar a nuestro cliente si no cuidamos a nuestro equipo. Debemos hacer cosas para el equipo en forma colectiva, y a la vez atender los problemas de cada individuo.

3. Poner atención a las promesas: no olvidar lo que prometimos entregar, aunque haya momentos de presión y de urgencias. Lo urgente no es lo importante, y lo más importante es cumplir las promesas.

4. Construir relaciones intencionalmente: la forma en que se desarrollan las relaciones entre miembros del equipo y con el cliente es decisiva para el éxito. No dejar esto librado a la suerte. Pensar al comienzo qué relaciones debemos desarrollar y nutrir, con quién y de qué forma.

5. Hacer y aprender: ir más allá de la acción. Aprovechar la acción para aprender, sacar conclusiones, preguntarse. Incorporar al proyecto sesiones para aprender nuevas cosas que se hayan descubierto.

6. Colaborar y trabajar en equipo: no hay otra forma de trabajar, no debe haberla. No esperar a que el proyecto se esté derrumbando para pedir ayuda. La ayuda debe ser consecuencia natural de la relación con todos los involucrados.

7. Escuchar más de lo que hablamos: tomarnos el tiempo para escuchar en fundamental en cualquier relación, y también en una relación de trabajo. Los líderes no sólo dan órdenes sino que también escuchan, preguntan y piden opiniones.

8. Manejar los grises: esperar lo inesperado, no todo es blanco y negro. Una de nuestras características más importantes debe ser la versatilidad.

Principales diferencias entre el PMBOK 2004 Tercera Edición y el PMBOK 2008 Cuarta Edición.

Principales diferencias entre el PMBOK 2004 Tercera Edición y el PMBOK 2008 Cuarta Edición.

Muchos profesionales nos preguntan cuáles son las principales diferencias entre el PMBOK 2004 Tercera Edición y el PMBOK 2008 Cuarta Edición.
Aquí van las principales diferencias:

1. Se redujo la cantidad de procesos de 44 a 42, nombrándolos uniformemente como verbo-sustantivo (antes esto era irregular). Dos procesos fueron borrados, dos procesos fueron agregados y seis procesos fueron transformados en cuatro (en el área de conocimiento de contrataciones).

2. Si hizo una distinción entre el documento del plan del proyecto y otros documentos para gestionar el proyecto. Se especificó qué contiene exactamente el documento del plan del proyecto ya que esto antes no estaba claro.

3. Se aclararon las diferencias en contenido del Project Charter (Acta del Proyecto) y el Scope Statement (Enunciado de Alcance).

4. Los diagramas de conexiones entre procesos que había en cada área de conocimiento fueron reemplazados por diagramas de flujo de datos, más fáciles de entender.

5. En general, se definieron mejor los factores de la empresa que afectan a un proyecto: cómo el entorno de negocios afecta el nacimiento y desarrollo normal de un proyecto. Esta idea está presente en varios capítulos del PMBOK 2008.

6. Se eligió un enfoque estandarizado para describir el proceso de cambios al proyecto, acciones preventivas, acciones correctivas y reparación de defectos.

7. Fue agregado un nuevo apéndice (G), que describe las habilidades interpersonales que debe tener un gerente de proyecto.

Para ver en detalle todas las diferencias entre las dos ediciones, leer el Apéndice A del PMBOK 2008 Cuarta Edición.
Otro cambio/agregado resulta un punto de acercamiento del nuevo PMBOK a términos y aportes positivos de otros enfoques. Es el agregado de la “gobernabilidad” de los proyectos y de los programas.Todos hemos escuchado este concepto, en especial en ámbitos de proyectos de sistemas.Y también hemos visto/vivido cómo muchos proyectos se salen de cauce por falta de método… y terminan ingobernables.El nuevo PMKoK tiene sólo unos párrafos, pero me pareció un acierto agregar este concepto.

Fuente IIAP