Vous pouvez toujours vérifier la vue du catalogue sys.columns
:
SELECT
c.NAME 'Col Name',
OBJECT_NAME(c.OBJECT_ID) 'Table Name',
t.name
FROM
sys.columns c
INNER JOIN
sys.types t ON c.system_type_id = t.system_type_id
WHERE
c.Name = 'your-column-name-here'
et sur cette base d'informations, vous pouvez générer les déclarations ALTER pour une base de données:
SELECT
'ALTER TABLE dbo.' + OBJECT_NAME(c.OBJECT_ID) +
' ALTER COLUMN ' + c.NAME ' NewDataType NULL'
FROM
sys.columns c
WHERE
c.Name = 'your-column-name-here'
Cette requête génère un ensemble d'instructions ALTER TABLE ....
que vous pouvez ensuite copier dans une fenêtre de requête SSMS et ex écrute. Avertissement: si l'une des colonnes est référencée - dans une relation de clé étrangère, ou s'il existe une contrainte par défaut ou une contrainte de vérification -, cette approche peut échouer. Dans ce cas, vous devez effectuer des étapes supplémentaires pour ces colonnes (par exemple, abandonner les contraintes, etc.)
Mise à jour: Cette opération permet de rechercher les colonnes définies dans les tableaux.
Si vous devez rechercher dans les procédures stockées, vue et ses fonctions ainsi, je recommande fortement l'utilisation excellente de Red-Gate et sans (!!) SQL Search utilitaire - des choses excellentes!
De quel type de données modifiez-vous et à quel type? –
Un problème: Même si vous aviez un tel script, il ne peut en aucun cas couvrir un SQL dynamique (instructions EXEC) ou un SQL ad hoc que votre application pourrait créer. – JohnFx
Je passe d'un bit à un varchar (1). – Aaron