“Nom de colonne non valide” erreur lors de l'appel d'insérer, après le tableau créé

Je suis le développement de script SQL, à l'aide de SSMS, qui apporte des modifications dans la base de données:

USE MyDatabase;

BEGIN TRANSACTION;

-- some statements

PRINT(N'#1');

IF (EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = N'dbo' AND TABLE_NAME = N'Table1' AND COLUMN_NAME = 'Table2_Id'))
BEGIN
    ALTER TABLE [dbo].[Table1] DROP CONSTRAINT [FK_Table1_Table2_Table2_Id];
    ALTER TABLE [dbo].[Table1] DROP COLUMN [Table2_Id];
    DROP TABLE [dbo].[Table2];

    PRINT(N'Table2 was dropped.');
END

PRINT(N'#2');

IF (NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = N'dbo' AND TABLE_NAME = N'Table2'))
BEGIN
    CREATE TABLE [dbo].[Table2]
    (
        [Id] INT NOT NULL PRIMARY KEY IDENTITY,
        [Number] INT NOT NULL UNIQUE,
        [Name] NVARCHAR(200) NOT NULL,
        [RowVersion] TIMESTAMP NOT NULL
    );
PRINT(N'Table2 was re-created.');
    INSERT INTO [dbo].[Table2]([Number], [Name]) VALUES(-1, N'Default value');
PRINT(N'Default value was inserted in Table2.');
END

-- some statements

COMMIT TRANSACTION;

Si Table1 a une colonne, nommé Table2_Id, puis de la base de données a deux tables (Table1 et Table2) et une relation de clé étrangère entre eux. Dans ce cas, j'ai besoin de:

  • drop de clé étrangère de la relation FK_Table1_Table2_Table2_Id;
  • chute de colonne de clé étrangère Table1.Table2_Id;
  • baisse Table2;
  • re-créer Table2, en utilisant le nouveau schéma de la table;
  • insérer la valeur par défaut dans Table2.

Quand je suis en train d'exécuter ce script, j'obtiens ces erreurs:

Msg 207, Niveau 16, État 1, Ligne 262 nom de colonne non Valide "Numéro".
Msg 207, Niveau 16, État 1, Ligne 262 nom de colonne non Valide 'Nom'.

Ressemble SQL Server utilise l'ancien schéma pour Table2 (qui en effet n'a pas ces colonnes), mais comment est-ce possible, si la table a juste créé avec le nouveau schéma?

Ce que je fais mal?

Version du serveur SQL Server 2012 (SP1) - 11.0.3128.0 (X64).

Mise à JOUR.

J'ai ajouté PRINT appels (voir le script ci-dessus). Il n'y a rien dans la fenêtre de message, à l'exception des messages d'erreur. Ainsi, le script n'est pas exécuté... Ce qui se passe??

OriginalL'auteur Dennis | 2013-04-23

  1. 11

    SQL Server essaie de compiler l'ensemble du lot. Si la table existe déjà, alors il sera de compiler en fonction de la pré-définition existante. La déclaration de référencement sur les nouvelles colonnes ne se compile pas et si le lot n'est jamais exécuté.

    Vous avez besoin de regrouper les déclarations à l'aide de la nouvelle définition dans un nouveau lot. Si vous exécutez ce dans SSMS il suffit d'insérer une GO

    USE MyDatabase;

BEGIN TRANSACTION;

-- some statements

PRINT(N'#1');

IF (EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = N'dbo' AND TABLE_NAME = N'Table1' AND COLUMN_NAME = 'Table2_Id'))
BEGIN
    ALTER TABLE [dbo].[Table1] DROP CONSTRAINT [FK_Table1_Table2_Table2_Id];
    ALTER TABLE [dbo].[Table1] DROP COLUMN [Table2_Id];
    DROP TABLE [dbo].[Table2];

    PRINT(N'Table2 was dropped.');
END

GO

PRINT(N'#2');

IF (NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = N'dbo' AND TABLE_NAME = N'Table2'))
BEGIN
    CREATE TABLE [dbo].[Table2]
    (
        [Id] INT NOT NULL PRIMARY KEY IDENTITY,
        [Number] INT NOT NULL UNIQUE,
        [Name] NVARCHAR(200) NOT NULL,
        [RowVersion] TIMESTAMP NOT NULL
    );
PRINT(N'Table2 was re-created.');
    INSERT INTO [dbo].[Table2]([Number], [Name]) VALUES(-1, N'Default value');
PRINT(N'Default value was inserted in Table2.');
END

COMMIT

    Sinon, vous pouvez exécuter la ligne incriminée dans un enfant lot

        EXEC(N'INSERT INTO [dbo].[Table2]([Number], [Name]) VALUES(-1, N''Default value'');')
    Merci pour l'explication... C' - "Si la table existe déjà, alors il sera de compiler selon le pré-existante de la définition de" - est l'un des plus stupides et pas évident de stratégie j'ai jamais pu l'imaginer... GO n'est pas une bonne option, le script est plutôt grand, et il y a quelques variables, déclarée en haut du script, qui est largement utilisé dans tout le script. De toute façon, merci, je vais réfléchir à une solution de contournement.
    Si vous ne voulez pas perdre vos variables, alors je suggère de fractionnement des différents lots (chute de / la création de tables ) pour séparer les procédures stockées, puis habillage de ceux-ci dans une procédure stockée principale.

    OriginalL'auteur Martin Smith