2

I was used to use alter script base on table dbVersion and each change in database was in if statement.

for example:

DECLARE @DbVersion BIGINT,
        @now DATETIME = GETDATE()

IF NOT EXISTS (SELECT 1 FROM sysobjects WHERE TYPE = 'U' and NAME = 'dbversion') BEGIN
    CREATE TABLE dbversion
    (
        Id                  BIGINT          NOT NULL    IDENTITY    PRIMARY KEY,
        Version             INT             NOT NULL,
        Description         NVARCHAR(2048)  NULL,
        Created             DATETIME2       NOT NULL    DEFAULT GETDATE(),
        Stamp               TIMESTAMP       NOT NULL
    )

    INSERT INTO dbversion (version, description, created)
    VALUES (0, 'Create version table for database', GETDATE())
END

SELECT @DbVersion = MAX(version) FROM dbversion

IF @DbVersion = 0 BEGIN
    CREATE TABLE AppUserRole
    (
        Id              BIGINT          NOT NULL    PRIMARY KEY,
        RoleName        NVARCHAR(16)        NOT NULL,
        RoleDescription NVARCHAR(64)        NOT NULL,
        CreatedDate     DATETIME2       NOT NULL    DEFAULT GETDATE()
    )

    INSERT INTO AppUserRole(Id, RoleName, RoleDescription, CreatedDate) 
    VALUES (1, 'role 1', 'role description', @now),
           (2, 'role 2', 'role description', @now),
           (3, 'role 3', 'role description', @now)

    SET @DbVersion = @DbVersion + 1

    INSERT INTO dbversion (version, description, created) 
    VALUES (@DbVersion, 'description', @now)
END

This is ok. I drop a column CreatedDate from table AppUserRole in next version:

IF @DbVersion = 1 
BEGIN
    ALTER TABLE AppUserRole DROP COLUMN CreatedDate

    SET @DbVersion = @DbVersion + 1

    INSERT INTO dbversion (version, description, created) 
    VALUES (@DbVersion, 'description', @now)
END

I am start to use SQL Server Management Studio v17.1 for SQL Server 13.0. In older version of Management Studio, the script always ran without errors.

In new version editor, I get an error

Invalid column name 'CreatedDate'

and the script does not even run.

This behavior will only begin when the table structure cache is updated - until then I can run the script over and over without errors.

In my opinion, Management Studio should not show this error, because in this location in script is no error in fact. If someone removes records in the dbVersion table, the error should occur at runtime.

When I try to debug this script, Management Studio will not allow it because the script ends on the first proper code (usually USE dbNAme)

Is there any way to prevent this script behavior? I use these structured DB scripts on many projects and I do not want to rewrite them - some are already very extensive.

Thank you

Vojtěch Dohnal
  • 7,867
  • 3
  • 43
  • 105
Davecz
  • 1,199
  • 3
  • 19
  • 43
  • have you more than one table "AppUserRole" in differents schemas?. Try to reference the schema like " ALTER TABLE [correct_schema].AppUserRole ...." – M84 Aug 04 '17 at 13:05
  • Sometimes I use more schemas, but mostly only dbo (as in this case). When I use multiple schemas, each table in the script is marked with this schema (newchema.AppUserRole), if only a dbo scheme, I do not mark the tables. – Davecz Aug 04 '17 at 13:10
  • Another two point to check, or you aren't connected to the database you think you are, or you aren't connected to the SQL Server instance you think you are. Are you sure about your connection string? Can you add a "select" before "..drop column" to check ? – M84 Aug 04 '17 at 13:13
  • I will always use these DB editing scripts as an administrator, and each of the scripts has a USE dbName command at the beginning - so I'm sure I'm on the right database. I have this new management studio only for local db, not for the production server (in the old version it works well) – Davecz Aug 04 '17 at 13:18
  • Do you run something else between these two scripts or run them consecutively? – M84 Aug 04 '17 at 13:32
  • run them consecutively – Davecz Aug 04 '17 at 13:34
  • try to finish the first script with one "GO" in the end. – M84 Aug 04 '17 at 13:35
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/151070/discussion-between-m84-and-davecz). – M84 Aug 04 '17 at 13:37
  • 1
    So you use the newest SSMS 2017 for SQL Server 2016, am I right? Tried this in SSMS 2016 against SQL Server 2016 and no problem. – Vojtěch Dohnal Aug 04 '17 at 13:37
  • Some variables are defined at the beginning of the script (like @dbVersion), and the go statements invalidate these variables – Davecz Aug 04 '17 at 13:39
  • Vojtěch Dohnal: you right. I am testing SSMS 2017 – Davecz Aug 04 '17 at 13:41
  • You attempt to DROP the COLUMN called CreateDate in your ALTER statement. Did you ever create this column? In your CREATE statement you named the column CreatedDate, which does not match the column name from your following ALTER statement. Could it be as simple as that? – dybzon Aug 04 '17 at 14:45
  • You have a TYPO in `ALTER TABLE AppUserRole DROP COLUMN CreateDate` should be `CreatedDate` – Vojtěch Dohnal Aug 04 '17 at 19:25
  • `DEFAULT (getdate())` creates a constraint, you will have to drop it first. I have tested it with SSMS 14.0.17119.0 (17.1) against SQL Server LocalDB 13.0.1601.5 and it has run without any problem. – Vojtěch Dohnal Aug 04 '17 at 19:29
  • I am unable to reproduce your problem, what are the exact versions of SSMS and SQL Server? – Vojtěch Dohnal Aug 05 '17 at 05:12
  • 1
    SQL Server: 13.0.4202.2 icrosoft SQL Server Management Studio 14.0.17119.0 Microsoft Analysis Services Client Tools 14.0.608.142 Microsoft Data Access Components (MDAC) 10.0.15063.0 Microsoft MSXML 3.0 6.0 Microsoft Internet Explorer 9.11.15063.0 Microsoft .NET Framework 4.0.30319.42000 Operating System 6.3.15063 – Davecz Aug 05 '17 at 06:41
  • I have run the first script and the second script against an empty database and the problem did not appear. On your PC it appears using empty database and just theese two scripts (opened each in a new query window) ? – Vojtěch Dohnal Aug 05 '17 at 18:13
  • The script is in one file – Davecz Aug 06 '17 at 08:57

0 Answers0