Scripting option difference between SSMS 2012 and all previous versions

Question

Hi,
I recently started to use SSMS 2012 (11.0.2100.60) and have seen some differences in scripting behavior of this version with previous ones (since V9). In previous versions when I want to modify a stored procedure, I right clicked on it
and selected “Modify”, and had a nice ALTER script. Now, I have a script using sp_executesql which is really not handy for SQL validation checks. After a research, I figured that I can change this behavior in the scripting options by changing the option “check
for object existence”. Great, it makes the deal!! In fact, no, because now, when I ask to script a DROP and CREATE on a table, I do not have the IF EXSIST part before the DROP anymore.
The behavior I try to have is:
When I hit “modify” on a procedure or other programmatic part, I would like to have an alter statement (DROP CREATE is fine too).
When I choose to script out an object as DROP and CREATE, I would like to have an existence check before the drop.
This is basically what SSMS did before the version 11 and was very helpful.
Regards,
Stef, DBA

Answer 1

Hi,
Thanks for your reply.
What do you think about the behavior?
Personally, I checked the links you sent. I cannot agree with sentences like “who cares about the outcome of the DROP when the CREATE
will still work”. When a script runs, it should run without errors, otherwise, how will you detect real issues in the noise? It’s like talking about “normal bug”. Also, “the create procedure must be in its own batch”, that’s what we did with the batch separator
GO.
A proper way to script database modifications (outside the tables itself) is to drop the object if it exists and to create it after.
Why? Because it works in any cases! Also, when I try to modify code, it’s convenient to have validation check against, and that’s why it’s convenient not to have dynamic code. It’s like coding large web sites in notepad. That’s what SSMS 10.50 and below did
perfectly.
I use script DROP CREATE capability when I prepare a migration script. Why should I write code when I have tools doing it for me? As
a DBA, I have to be critic about the script generated and to adapt it if necessary. The MODIFY option is when I debug some code. I expect the tool to validate as much mistakes as possible (yes I do mistakes and I admit it). Like I said before, it’s like working
with notepad as coding tool, it works, but who will do it?
I really would like to know if I’m alone on this position.
Just to make it easier to understand for other people, the following code is what is generated.
With SSMS 10.50.2806.0 (include IF NOT EXISTS clause = true):
Scripting a table as “DROP and CREATE”:
IF 
EXISTS
(SELECT
FROM
sys.objects
WHERE
object_id
=
OBJECT_ID(N'[dbo].[ScrapTable]')
AND
type
in
(N'U'))
DROP
TABLE [dbo].[ScrapTable]
GO
CREATE
TABLE [dbo].[ScrapTable](
                [ScrapID] [int]
NOT
NULL
ON [PRIMARY]
GO
Right click on my stored procedure and hit “Modify”:
ALTER
PROCEDURE [dbo].[GetScrap]
AS
BEGIN
SET
NOCOUNT
ON;
SELECT
FROM dbo.ScrapTable
END
With SSMS 11.0.2200.60 (check for object existence = false):
Scripting a table as “DROP and CREATE”:
DROP
TABLE
[dbo].[ScrapTable]
GO
CREATE
TABLE
[dbo].[ScrapTable](
[ScrapID]
[int]
NOT
NULL
ON
[PRIMARY]
GO
Right click on my stored procedure and hit “Modify”:
ALTER
PROCEDURE
[dbo].[GetScrap]
AS
BEGIN
SET
NOCOUNT
ON;
SELECT
FROM
dbo.ScrapTable
END
With SSMS 11.0.2200.60 (check for object existence = true):
Scripting a table as “DROP and CREATE”:
IF 
EXISTS
(SELECT
FROM
sys.objects
WHERE
object_id
=
OBJECT_ID(N'[dbo].[ScrapTable]')
AND
type
in
(N'U'))
DROP
TABLE
[dbo].[ScrapTable]
GO
IF
NOT
EXISTS
(SELECT
FROM
sys.objects
WHERE
object_id
=
OBJECT_ID(N'[dbo].[ScrapTable]')
AND
type
in
(N'U'))
BEGIN
CREATE
TABLE
[dbo].[ScrapTable](
[ScrapID]
[int]
NOT
NULL
ON
[PRIMARY]
END
GO
Right click on my stored procedure and hit “Modify”:
IF 
EXISTS
(SELECT
FROM
sys.objects
WHERE
object_id
=
OBJECT_ID(N'[dbo].[GetScrap]')
AND
type
in
(N'P',
N'PC'))
BEGIN
EXEC
dbo.sp_executesql
@statement
=
N'ALTER PROCEDURE [dbo].[GetScrap]
AS
BEGIN
                SET NOCOUNT ON;
                SELECT * FROM dbo.ScrapTable
END
END
SSMS 11.0 does it definitely in another way.
Regards,
Stef, DBA