[ad]

Este bug esta com a correção prevista para o Cumulative Update de Junho, por isso achei importante traduzir o post do meu amigo Brian Smith.

Os passos abaixo são para evitar o problema e corrigir caso tenha ocorrido.

Sintomas:

Linhas de base orfãs causam erro ao publicar. O trabalho na fila é parado com o seguinte status Falha, Mas sem Bloqueio de Correlação. No detalhe do erro você verá alguma coisa parecida com:

ReportingProjectChangeMessageFailed (24006) – The INSERT statement conflicted with the FOREIGN KEY constraint “FK_MSP_EpmTaskBaseline_ProjectUID_TaskUID”. The conflict occurred in database “ProjectServer_Reporting”, table “dbo.MSP_EpmTask”. The statement has been terminated..

GeneralQueueJobFailed (26000) – ReportingProjectPublish.ReportProjectPublishMessageEx

Estas falhas acontecem na ação de reporting na fila, logo isso significará que os relatórios com base no banco de dados Reporting e qualquer atualização do cubo OLAP poderá estar desatualizada.

Causa:

A raiz de todos esses problemas é que quando você usa qualquer uma das opções Salvar e Enviar (XML, CSV, Excel, etc).

Ao executar essa ação o Project incorretamente altera alguns valores internos de algumas entidades como tarefas e calendários.

Como evitar:

Se você precisa usar o Salvar e Enviar, então a melhor prática até que solte a correção para isso é primeiro salvar o plano para o servidor, e publicar (caso queira). Em seguida, faça o que você precisa com o Salvar e Enviar, e, em seguida, feche o projeto sem salvar e dando check-in. Lembre-se de NÃO salvar quando for questionado, você já salvou antes da ação de Salvar e Enviar, logo pode descartar este ultimo salvar. Como a versão local do cache terá sido “corrompida”, neste caso deve-se excluir o projeto do cache local apenas depois que o check-in estiver concluído.

AVISO – as seguintes etapas são consultas diretas nos bancos de dados do Project Server – por favor, certifique-se que você está trabalhando com as bases de dados adequadas ao usar estes – e ter um backup de banco de dados, se algum problema ocorrer.
A detecção desta condição é bastante simples, pois estamos apenas à procura de linhas de base de tarefas que não existem, portanto, a seguinte consulta no banco de dados Draft irá fazer isso:

— Detect for orphan baseline task records that can cause reporting publish job failures.

USE ProjectServer_Draft — specify the appropriate draft database

select PROJ_NAME, MTB.PROJ_UID,TASK_UID,TB_BASE_NUM from MSP_TASK_BASELINES MTB
inner join MSP_PROJECTS MP on MTB.proj_uid=MP.proj_uid
where TASK_UID not in (select TASK_UID from MSP_TASKS)

Isto irá retornar as linhas aonde o erro existe – e identificar quais projetos são afetados. Lembre-se de remover o projeto do cache local na máquina dos Gerentes de Projeto, caso contrário eles irão fazer o erro voltar.
Os próximos scripts fazem a limpeza no banco de dados, e eles são simplesmente a exclusão dos registros das tarefas são inexistentes.

— Script to run on the draft DB
USE ProjectServer_Draft — specify the appropriate draft database

delete from MSP_TASK_BASELINES where TASK_UID not in (select TASK_UID from MSP_TASKS)

— Script to run on the published DB
USE ProjectServer_Published — specify the appropriate published database

delete from MSP_TASK_BASELINES where TASK_UID not in (select TASK_UID from MSP_TASKS)

Espero que isso ajude a compreender o problema e a forma de evitá-lo até que a correção venha.

Se você precisar de alguma ajuda com estes passos, sinta-se livre para abrir um chamado de suporte – lembrando que, como isto é um bug o chamdo não é cobrado.

Abraços,

André Xavier