2

Using SQL Server Management Studio, my issue stems from a database creation script. The script is written to create a database, many of whose tables have an identity column:

CREATE TABLE Workshop
(
    WorkshopID int IDENTITY,
    WorkshopName varchar(40) NOT NULL,
    Description varchar(800),
    CONSTRAINT PK_Workshop PRIMARY KEY (WorkshopID)
);

My issue is that even with the script plainly creating a column as an identity column, after the script runs none of the columns that should be identity columns actually have that column set to be identity.

To clarify: Running the above code will create that table as specified except WorkshopID will not be an identity column.

What needs to change so that the script will work as written?

Aaron Bertrand
  • 272,866
  • 37
  • 466
  • 490
Valevalorin
  • 390
  • 1
  • 3
  • 18
  • 1
    How are you validating that `WorkshopID` is not an `IDENTITY` column? – Aaron Bertrand Nov 27 '12 at 21:33
  • After experiencing errors with a program that manages the database, I went into SSMS and looked at the design of the tables and all columns that should've been identity columns had "(Is Identity)" set to "No" in their column properties. – Valevalorin Nov 27 '12 at 21:47
  • Ok, and you ran the script in SSMS, and did you verify after running the script (and before running your program or doing anything else) that the tables were created without the identity property, even though your script says to do so and the script ran successfully? Are you sure it didn't generate errors that you ignored, and that you ran it in the exact same database you're checking and that the program runs in? I ran your script and it created the table with the identity property, so there's some piece of information not lining up here. – Aaron Bertrand Nov 27 '12 at 21:49
  • @AaronBertrand I also checked the identity by refreshing the Object Explorer and then opening the Design view on the table when I saw the same behavior Kelly describes. I wonder if what we're seeing is an intermittent bug in SSMS refreshing rather than a failure in the table creation? – JamieSee Nov 27 '12 at 22:23
  • @JamieSee I couldn't reproduce, or find any existing bug. What version of Management Studio are you using? Have you applied any service packs? – Aaron Bertrand Nov 27 '12 at 22:26
  • @Kelly have you already fixed all the tables in question? If not can you run `SELECT name, is_identity FROM sys.columns WHERE object_id = OBJECT_ID('Workshop') AND name = 'WorkshopID'` to see if the identity is correct in the db but wrong in SSMS? – JamieSee Nov 27 '12 at 22:30
  • @AaronBertrand In my case, the SSMS build is 10.50.4000. That's 2008 R2 SP2. – JamieSee Nov 27 '12 at 22:33
  • @JamieSee if you can reproduce, by all means, file a bug at http://connect.microsoft.com/sql – Aaron Bertrand Nov 27 '12 at 22:34
  • @AaronBertrand The problem is that I was only able to reproduce it once. Every subsequent attempt, I haven't been able to get it to happen again. If it is an SSMS bug, it must take a pretty specific set of circumstances to set it off. I'd love to see the results of the query I gave if Kelly can get it to happen again. – JamieSee Nov 27 '12 at 22:38

1 Answers1

0

FYI, if you generate script for this using SQL Management Studio's designer, this is the resulting script:

/* To prevent any potential data loss issues, you should review this script in detail before running it outside the context of the database designer.*/
BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
COMMIT
BEGIN TRANSACTION
GO
CREATE TABLE dbo.Table_1
    (
    WorkshopID int NOT NULL IDENTITY (1, 1),
    WorkshopName varchar(40) NOT NULL,
    Description varchar(800) NULL
    )  ON [PRIMARY]
GO
ALTER TABLE dbo.Table_1 ADD CONSTRAINT
    PK_Table_1 PRIMARY KEY CLUSTERED 
    (
    WorkshopID
    ) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,   ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

GO
ALTER TABLE dbo.Table_1 SET (LOCK_ESCALATION = TABLE)
GO
COMMIT

If you create the table and then script it using the Create To... menu option you get a completely different script:

USE [MyDatabase]
GO

/****** Object:  Table [dbo].[Workshop]    Script Date: 11/27/2012 14:05:33 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[Workshop](
    [WorkshopID] [int] IDENTITY(1,1) NOT NULL,
    [WorkshopName] [varchar](40) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
    [Description] [varchar](800) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
 CONSTRAINT [PK_Workshop] PRIMARY KEY CLUSTERED 
(
    [WorkshopID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON,    ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO
JamieSee
  • 12,696
  • 2
  • 31
  • 47
  • No, the `NOT NULL` designation is not required, especially when it is enforced via the `PRIMARY KEY` anyway. – Aaron Bertrand Nov 27 '12 at 21:36
  • Although not required I would recommend always adding your seed and increment values `CREATE TABLE Workshop ( WorkshopID int IDENTITY(1,1) NOT NULL, WorkshopName varchar(40) NOT NULL, Description varchar(800), CONSTRAINT PK_Workshop PRIMARY KEY (WorkshopID) );` – Nic Nov 27 '12 at 21:43
  • @Nic Neither of these suggestions address the actual issue, though. – Aaron Bertrand Nov 27 '12 at 21:47
  • @AaronBertrand Actually the NOT NULL is necesary as you'll see if you run both scripts. I did exactly that in SQL 2008 R2 before posting. Perhaps this is because the creation of the constraint that would force the NOT NULL behavior gets processed after the initial creation? – JamieSee Nov 27 '12 at 21:48
  • @JamieSee I'm not sure I understand what you mean by `is necessary`. I was able to create a table using the script in the question, and the table has the identity property and it works as it should. I did not at any point need to say `NOT NULL`... – Aaron Bertrand Nov 27 '12 at 21:50
  • @JamieSee The not null is not necessary. The particular exception the program that manages the database would throw is 515 which is cannot insert null into a column that doesn't accept nulls. – Valevalorin Nov 27 '12 at 21:51
  • I cannot repro the issue. When I run the initial script against 2008R2 SP2 and 2012 it creates the table and the WorkshopID is an integer primary key which is an identity seeding 1, incrementing 1 – Nic Nov 27 '12 at 21:51
  • @AaronBertrand Could you do something for me. In SSMS can you go to Tools -> Options, and then select "Designers" from the tree at the left, and then see if "Prevent saving changes that require table re-creation is checked or unchecked. – Valevalorin Nov 27 '12 at 21:54
  • @Kelly huh? I'm not sure what on earth that has to do with anything here. I don't use the designers to create or modify tables and I certainly didn't do so in this case. – Aaron Bertrand Nov 27 '12 at 21:55
  • @AaronBertrand Interesting... I was able to repro the problem once and thought the NOT NULL was significant. However, I just ran the original script in the question again, and it did not do it this time. Very strange. – JamieSee Nov 27 '12 at 22:04
  • @AaronBertrand Before I could manually change the columns to be identity columns I had to make sure that option was unchecked. That is why I ask. My current theory is that when I run the creation script that option must be unchecked. – Valevalorin Nov 27 '12 at 22:08
  • @Kelly when you run that script in a query window, that setting is 110% irrelevant (in only has anything to do with the *visual designers*). – Aaron Bertrand Nov 27 '12 at 22:13
  • @Kelly If you run either of the Managment Studio generated scripts that I added to create a table does it fail to make the identity? – JamieSee Nov 27 '12 at 22:17
  • @JamieSee I ran the second script and the table was created with identity. – Valevalorin Nov 27 '12 at 22:25
  • @JamieSee The next question I have is what is the difference that makes your script work but mine not. – Valevalorin Nov 27 '12 at 22:33
  • @Kelly I'm starting to wonder if your script actually did work. If you run your script again, do you still see the same behavior. If you do, can you run that SELECT query I gave after? – JamieSee Nov 27 '12 at 22:43