Salve a tutti,
Ho avuto una doccia fredda, ma devo arrendermi alla realta'.
Ho sempre creduto che la definizione Identity sottintendesse a campo a valori univoci, ma ho scoperto che non e' cosi'.
Avevo impostato un campo in una tabella (in cui erano gia' stati definiti dei campi a PK) come IDENTITY ed impostatoci un indice come univoco. Questo in un database MSDE. Devo dire che nel tempo la tabella si e' sempre comportata correttamente, il sottinteso campo si e' sempre comportato come univoco. Nel corso del tempo questo DB ha subito delle trasformazioni, da SQL2005 fino a SQL2012. Improvvisamente, nell'eseguire uno script di aggiornamento, dove veniva usata la suddetta tabella, ho scoperto un errore di vincolo sull'univocita' dell' indice sul campo identity. Cosa e' successo? In quale passaggio il campo ha subito la duplicazione nei suoi valori? Gli script di modifica sono sempre stati quelli generati da SQL Server Management Studio; non sono mai stati forzati degli inserimenti "manuali" di valori nel campo implicato, tutto e' sempre stato lasciato alla gestione di SQL Server.

Dopo questa amara constatazione, devo cambiare la pratica di assegnare alle tabelle la chiave primaria su un campo Identity? Qual'e' allora la pratica migliore? Come assegnare ad una tabella una chiave primaria univoca automaticamente?
Grazie.

Ciao, grazie per la risposta.
Dunque, se ho capito, un campo Identity di per se non garantisce una serie univoca di valori, ma se il campo e' implicato in una chiave primaria oppure una chiave univoca, allora i valori generati sono univoci, giusto? Cosa che, per altro, ho sempre perseguito nei miei DB.
Il mio dubbio e' nato da questo: ho una serie di database, tutti omologhi e disposti sulle più svariate versioni (da MSDE a SQL EXPRESS 2012), questo campo e' rimasto univoco fino al suo approdo su 2012, allorche' mi sono accorto che la modifica di un campo, operata tramite script generato da SQL Server Management su un DB MSDE, causava una eccezione nel ricostruire la chiave univoca sul campo Identity sul DB su 2012. Nelle altre istanze invece nessun problema. E' sempre stata mia abitudine impostare un PK su un campo identity, ma in questo caso ho ereditato il db cosi' come era stato impostato. Riassumendo, puo' l'esecuzione di uno script duplicare il contenuto di un campo identity preesistente? L'esecuzione della SELECT INTO (da tabella originaria a tabella d'appoggio) puo' duplicare nella tabella di destinazione dei valori che non lo erano nella tabella d'origine?
Saluti