Creating Scripts via Query Analyzer or Enterprise Manager

I'm trying to decide what is the best practice in terms of creating scripts
that, for instance, update an existing database. It seems there are a
couple of ways to do this (although I am sure there are more). It is often
suggested that you code your changes, by hand, using Enterprise Manager. As
I am looking at examples how to do this, I understand some of the basics of
doing this. For instance, if I have a tabled called Numbers and there is a
field named Employee (data type int, length 4, non nullable) that I want to
add a unique constraint to, it seems that most examples have the following
simplistic syntax:
ALTER TABLE Numbers
ADD CONSTRAINT EmployeeUnique
UNIQUE(Employee)
If I make the same change via Enterprise Manager and then click the Save
Change Script button, the amount of code it creates is much more:
BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
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
ALTER TABLE dbo.Numbers ADD CONSTRAINT
IX_Numbers UNIQUE NONCLUSTERED
(
Employee
) ON [PRIMARY]
GO
COMMIT
So, is all of this extra code necessary? Are the examples I am looking at
too simplistic? Is it OK to use EM to make changes and then generate the
scripts?
Thanks.
It si absolutely Ok to that in QA (the way you did).
All these SET statements, generated by EM, are actually happening whenever
you create a new session in QA, BUT behind the scene. You may see this if
you trace tsql exec from QA by Profiler.
With transactions is the same situation: in case of implicit transactions,
new T-SQL statement starts a new transaction. This explains Begin-commit
blocks inside EM-generated code.
All these settings are server defaults and can be changed.
Regards,
Marko Simic
"epigram" wrote:

> I'm trying to decide what is the best practice in terms of creating scripts
> that, for instance, update an existing database. It seems there are a
> couple of ways to do this (although I am sure there are more). It is often
> suggested that you code your changes, by hand, using Enterprise Manager. As
> I am looking at examples how to do this, I understand some of the basics of
> doing this. For instance, if I have a tabled called Numbers and there is a
> field named Employee (data type int, length 4, non nullable) that I want to
> add a unique constraint to, it seems that most examples have the following
> simplistic syntax:
> ALTER TABLE Numbers
> ADD CONSTRAINT EmployeeUnique
> UNIQUE(Employee)
> If I make the same change via Enterprise Manager and then click the Save
> Change Script button, the amount of code it creates is much more:
> BEGIN TRANSACTION
> SET QUOTED_IDENTIFIER ON
> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
> 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
> ALTER TABLE dbo.Numbers ADD CONSTRAINT
> IX_Numbers UNIQUE NONCLUSTERED
> (
> Employee
> ) ON [PRIMARY]
> GO
> COMMIT
>
> So, is all of this extra code necessary? Are the examples I am looking at
> too simplistic? Is it OK to use EM to make changes and then generate the
> scripts?
> Thanks.
>
>
|||Do you save all your change scripts so you have a complete audit trail of all
changes made to your database? How you make the changes is just one part of
database change management. Check out this article on the subject
http://www.innovartis.co.uk/pdf/Inno...ange_Mgt. pdf
This is an article showing an approach to database change managment that
will always work and gives you a complete audit trail on all database changes
without slowing down the development of the database. It was the foundation
of the software called DB Ghost (http://www.dbghost.com)
How the database is developed (whether you use Query Analyzer, Enterprise
Manager or other third party tools) holds little relevance to the larger
problems of deploying those changes and having a clear picture of what has
changed, when it was changed, who it was changed by - so any problems can be
quickly solved in a repeatable and totally auditable manner. This (I believe)
is the essence of database change management.
Excuse me for ranting, however I find it very frustrating watching the same
mistakes repeated time and again...
"epigram" wrote:

> I'm trying to decide what is the best practice in terms of creating scripts
> that, for instance, update an existing database. It seems there are a
> couple of ways to do this (although I am sure there are more). It is often
> suggested that you code your changes, by hand, using Enterprise Manager. As
> I am looking at examples how to do this, I understand some of the basics of
> doing this. For instance, if I have a tabled called Numbers and there is a
> field named Employee (data type int, length 4, non nullable) that I want to
> add a unique constraint to, it seems that most examples have the following
> simplistic syntax:
> ALTER TABLE Numbers
> ADD CONSTRAINT EmployeeUnique
> UNIQUE(Employee)
> If I make the same change via Enterprise Manager and then click the Save
> Change Script button, the amount of code it creates is much more:
> BEGIN TRANSACTION
> SET QUOTED_IDENTIFIER ON
> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
> 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
> ALTER TABLE dbo.Numbers ADD CONSTRAINT
> IX_Numbers UNIQUE NONCLUSTERED
> (
> Employee
> ) ON [PRIMARY]
> GO
> COMMIT
>
> So, is all of this extra code necessary? Are the examples I am looking at
> too simplistic? Is it OK to use EM to make changes and then generate the
> scripts?
> Thanks.
>
>