Risolvere conflitti di schema che si verificano nel data warehouse

I conflitti di schema si verificano quando un set di attributi per i campi segnalabili differisce fra le raccolte di progetti team. Quando si verifica un conflitto di schema, i campi non in conflitto vengono elaborati normalmente, mentre ai campi in conflitto vengono assegnati valori null finché non vengono risolti, quindi vengono elaborati normalmente. Inoltre, il sistema genera un evento di notifica per ogni conflitto rilevato. Con la sottoscrizione all'evento, è possibile ricevere avvisi quando si verificano conflitti di schema per qualsiasi progetto team definito per una raccolta. È necessario correggere tutti i conflitti di schema per sbloccare l'elaborazione dei dati associati per il warehouse e per consentire ai report associati di visualizzare i dati correnti.

Tutti i dati segnalabili da tutti i progetti team definiti in tutte le raccolte di progetti per una distribuzione di Visual Studio Team Foundation Server sono scritti in un unico data warehouse relazionale. I dati dal warehouse vengono quindi elaborati e scritti nel cubo. La raccolta di dati in un solo data warehouse supporta la creazione di report fra gli insiemi di progetti team. Tuttavia, poiché i campi vengono gestiti in modo distinto per ogni raccolta di progetti, possono verificarsi conflitti di schema quando definizioni diverse vengono assegnate a uno o più attributi di un campo assegnato allo stesso nome di riferimento di report.

Contenuto dell'argomento

• Messaggi di errore che segnalano conflitti di schema

• Origini dei conflitti di schema

• Risolvere i conflitti di schema

• Verificare che i conflitti di schema siano stati risolti

Messaggi di errore che segnalano conflitti di schema

Quando si verifica un conflitto di schema, viene visualizzato un messaggio di errore nelle seguenti posizioni:

• Il log eventi per il server a livello applicazione.

  Nota

  Team Foundation Server registra un messaggio di errore nel log eventi ogni giorno finché il conflitto di dati non viene risolto.

• Un report fornito con i modelli di processo MSF e visualizzato tramite Gestione report.

• Un dashboard fornito con i modelli di processo MSF e visualizzato tramite il portale del progetto.

  Nota

  È possibile determinare il report o il dashboard aggiornato più di recente osservando il timestamp Data ultimo aggiornamento, visualizzato nell'angolo in basso a destra di ogni report e dashboard.Il timestamp corrisponde alla data/ora più recente in cui è stata completata correttamente l'esecuzione di ogni processo della scheda del warehouse pianificato per il completamento per ogni raccolta di progetti.Il calcolo del timestamp include i processi della scheda personalizzati e ignora i processi della scheda per i quali è bloccata l'esecuzione del servizio Web del controllo warehouse.

  Se un conflitto di schema sta bloccando l'inserimento di dati nel data warehouse per un report, il timestamp del report non verrà aggiornato.

Oltre ai messaggi precedenti, è possibile ottenere altre informazioni usando l'operazione GetProcessingStatus del servizio Web del controllo warehouse. Per altre informazioni, vedere Elaborare manualmente il data warehouse e il cubo di Analysis Services per Team Foundation Server.

Origini dei conflitti di schema

I conflitti di schema si verificano quando un amministratore di progetto esegue una delle seguenti azioni:

• Aggiunge un campo segnalabile a un tipo di elemento di lavoro in una raccolta di progetti e gli attributi assegnati a quel campo non corrispondono a quelli nelle altre raccolte di progetti.

• Modifica un attributo assegnato a un campo elemento di lavoro usato in più raccolte di progetti, anche se queste modifiche sono in conflitto con le assegnazioni in altre raccolte.

  Nota

  Un amministratore di progetto può evitare gli errori nell'elenco precedente rivedendo le assegnazioni di attributi per i campi definiti in più raccolte di progetti in una distribuzione.

Gli errori si verificano quando un campo ha lo stesso nome di riferimento o lo stesso nome di riferimento di report in più raccolte di progetti e uno o più dei seguenti attributi per il campo non corrispondono in due o più raccolte:

• name: il nome descrittivo del campo, visualizzato quando si crea una query elemento di lavoro.

• reportingname: il nome visualizzato nei report. Se non viene specificato alcun valore, verrà usato il valore assegnato all'attributo name.

• reportable/reportingtype: se i dati del campo sono disponibili per essere inclusi nei report e, in caso affermativo, il tipo segnalabile (ad esempio, None, Detail, Dimension o Measure).

  Nota

  L'elemento FIELD usava l'attributo reportable, mentre il comando witadmin changefield usa l'attributo reportingtype.Questi attributi definiscono le stesse informazioni.

• type: il tipo di dati accettato dal campo (ad esempio, Integer, HTML, String, Double o DateTime).

La tabella seguente fornisce degli esempi di assegnazione degli attributi che causano conflitti di schema. In questi esempi il nome di riferimento di report e il nome di report non sono assegnati.

Attributo	Raccolta di progetti 1	Raccolta di progetti 2	Conflitto di schema
Tipo	Stringa	Integer	I tipi di dati non corrispondo.
ReportingName	Attività	Attività comune	I nomi di report non corrispondono.
Segnalabile	Dettagli	Dimensione	I tipi di report non corrispondono.

Risolvere i conflitti di schema

È possibile rivedere il log eventi nel server a livello applicazione per ottenere altre informazioni sul campo che sta causando un conflitto di schema. Dopo aver individuato il campo o i campi che causano il conflitto, seguire questa procedura:

1. Rivedere gli attributi assegnati al campo in tutte le raccolte di progetti. È possibile usare il comando witadmin listfields, che ha la seguente sintassi:

   witadmin listfields /collection:CollectionURL /n:RefName [/unused]
   

   Per altre informazioni, vedere Gestire campi di elementi di lavoro [witadmin].

2. Determinare le modalità di risoluzione del conflitto:

   • Modificare l'attributo per il campo in una raccolta di progetti per farlo corrispondere alle assegnazioni eseguite in altre raccolte di progetti. Eseguire questa operazione quando i team usano il campo con le stesse modalità usate in report simili o per la creazione di report tra progetti.

   • Etichettare di nuovo il nome di riferimento di report per il campo in conflitto. Eseguire questa operazione quando i campi vengono usati in modo diverso oppure se è necessario mantenere un campo diverso. In questo caso, il campo non viene usato dai team che lavorano in raccolte di progetti diverse per la creazione di report tra progetti.

     Per altre informazioni, vedere Aggiungere o modificare campi di elementi di lavoro per supportare la creazione di rapporti.

   • Contrassegnare un campo come non segnalabile per una o più raccolte. Eseguire questa operazione quando il campo non viene usato per i report relativi alle raccolte di progetti specificate.

   • Rimuovere il campo dalla raccolta di progetti team. Eseguire questa operazione quando il campo non viene usato da progetti team o report.

     Nota

     Se si rimuove un campo usato in un report, il report non verrà visualizzato correttamente.

3. Modificare l'attributo assegnato a un campo in base alle decisioni prese nel passaggio precedente. È possibile usare il comando witadmin changefield, che ha la seguente sintassi:

   witadmin changefield /collection:CollectionURL /n:RefName [/name:NewName] [/syncnamechanges:true | false] [/reportingname:ReportingName] [/reportingrefname:ReportingRefName] [/reportingtype:Type] [/reportingformula:Formula] [/noprompt]
   

4. Per eliminare un campo da una raccolta di progetti, è possibile usare il comando witadmin deletefield con la seguente sintassi:

   witadmin deletefield /collection:CollectionURL /n:RefName
   

   Importante

   Se si elimina in modo permanente un campo, il campo viene rimossi insieme a tutti i dati archiviati nell'archivio dati.

Verificare che i conflitti di schema siano stati risolti

È possibile verificare se i conflitti di schema siano stati risolti elaborando i data warehouse su richiesta, quindi controllando i report per determinare se siano aggiornati. In alternativa, è possibile attendere l'esecuzione dei processi della scheda del warehouse in base alla pianificazione predefinita. Per impostazione predefinita, il database relazionale viene elaborato a intervalli di pochi minuti. Il cubo di Analysis Services, invece, viene elaborato ogni due ore per impostazione predefinita.

Nota

Per altre informazioni sul servizio Web del controllo warehouse, vedere Elaborare manualmente il data warehouse e il cubo di Analysis Services per Team Foundation Server.

1. Elaborare il data warehouse relazionale su richiesta usando l'operazione ProcessWarehouse di WarehouseControlService.

2. Elaborare il cubo su richiesta usando l'operazione ProcessAnalysisDatabase di WarehouseControlService.

3. Aprire un dashboard o Gestione report e verificare che i report vengano aggiornati. Per altre informazioni, vedere Dashboard del portale del progetto o Rapporti (SQL Server Reporting Services).

Se vengono ancora visualizzati i messaggi di errore, è possibile ottenere altre informazioni sul conflitto di dati e sulle schede bloccate interessate eseguendo l'operazione GetProcessingStatus di WarehouseControlService.

Vedere anche

Riferimenti

Gestire campi di elementi di lavoro [witadmin]

Concetti

Aggiungere o modificare campi di elementi di lavoro per supportare la creazione di rapporti

Grafici, dashboard e report per Visual Studio ALM

Altre risorse

Elaborare manualmente il data warehouse e il cubo di Analysis Services per Team Foundation Server