Quando si ha a che fare con l'eliminazione di dati da tabelle che hanno relazioni di chiave esterna - che è fondamentalmente il caso di qualsiasi database progettato correttamente - possiamo disabilitare tutti i vincoli, eliminare tutti i dati e quindi riattivare i vincoli
-- disable all constraints
EXEC sp_MSForEachTable "ALTER TABLE ? NOCHECK CONSTRAINT all"
-- delete data in all tables
EXEC sp_MSForEachTable "DELETE FROM ?"
-- enable all constraints
exec sp_MSForEachTable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"
Maggiori informazioni sulla disabilitazione di vincoli e trigger qui
se alcune tabelle hanno colonne di identità, potremmo volerle reinsediare
EXEC sp_MSForEachTable "DBCC CHECKIDENT ( '?', RESEED, 0)"
Nota che il comportamento di RESEED differisce tra una tabella nuova di zecca e una che aveva avuto alcuni dati inseriti in precedenza da BOL:
DBCC CHECKIDENT ('table_name', RESEED, newReseedValue)
Il valore dell'identità corrente è impostato su newReseedValue. Se nessuna riga è stata inserita nella tabella da quando è stata creata, la prima riga inserita dopo l'esecuzione di DBCC CHECKIDENT utilizzerà newReseedValue come identità. In caso contrario, la riga successiva inserita utilizzerà newReseedValue + 1. Se il valore di newReseedValue è inferiore al valore massimo nella colonna identity, verrà generato il messaggio di errore 2627 sui successivi riferimenti alla tabella.
Grazie a Robert per aver sottolineato il fatto che la disabilitazione dei vincoli non consente di utilizzare tronca, i vincoli dovrebbero essere eliminati e quindi ricreati
