Script Question

Is there any easy way to create a change script as illustrated below for all tables within a database?

Right now I would have to create a seperate script for each table.

I would like to be able to update the customers database while preserving their exisiting data.

------------------------

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
CREATE TABLE dbo.Tmp_Deposits
(
DEPSYSID int NOT NULL IDENTITY (1, 1),
DEPBANKID int NULL,
DEPUSER varchar(50) NULL,
DEPSTATUS tinyint NULL,
CHECKORCASH varchar(10) NULL,
CHECKNUMBER varchar(10) NULL,
DEPOSITSOURCE varchar(50) NULL,
DEPAMOUNT decimal(9, 2) NULL,
CASHDRAWERID int NULL,
DEPOSITDATE datetime NULL,
ACTUALDEPOSITUSER varchar(50) NULL,
ACTUALDEPOSITDATE datetime NULL
) ON [PRIMARY]
GO
SET IDENTITY_INSERT dbo.Tmp_Deposits ON
GO
IF EXISTS(SELECT * FROM dbo.Deposits)
EXEC('INSERT INTO dbo.Tmp_Deposits (DEPSYSID, DEPBANKID, DEPUSER, DEPSTATUS, CHECKORCASH, CHECKNUMBER, DEPOSITSOURCE, DEPAMOUNT, CASHDRAWERID, DEPOSITDATE, ACTUALDEPOSITUSER, ACTUALDEPOSITDATE)
SELECT DEPSYSID, DEPBANKID, DEPUSER, DEPSTATUS, CHECKORCASH, CHECKNUMBER, DEPOSITSOURCE, DEPAMOUNT, CASHDRAWERID, DEPOSITDATE, ACTUALDEPOSITUSER, ACTUALDEPOSITDATE FROM dbo.Deposits TABLOCKX')
GO
SET IDENTITY_INSERT dbo.Tmp_Deposits OFF
GO
DROP TABLE dbo.Deposits
GO
EXECUTE sp_rename N'dbo.Tmp_Deposits', N'Deposits', 'OBJECT'
GO
ALTER TABLE dbo.Deposits ADD CONSTRAINT
DEP_SYSID PRIMARY KEY CLUSTERED
(
DEPSYSID
) ON [PRIMARY]

GO
CREATE NONCLUSTERED INDEX DEP_STATUS ON dbo.Deposits
(
DEPSTATUS
) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX DEP_Date ON dbo.Deposits
(
DEPOSITDATE
) ON [PRIMARY]
GO
COMMIT

------------------------

--
Tim Morrison

------------------------

Vehicle Web Studio - The easiest way to create and maintain your vehicle related website.
http://www.vehiclewebstudio.comHi

In general this task would not be needed if you kept the database objects in
a source code control system. You can do it by comparing two different
databases (pre changes and post changes) and compare the system schemas
using three part naming convensions and cursors.
Alternatively get something like red gate compare http://www.red-gate.com to
do it for you. This question does get asked quite frequently in the news
groups so you may want to check Google for other solutions.

It may also be possible to do this from VISIO if you are modelling the
database.

John

"Tim Morrison" <sales@.kjmsoftware.com> wrote in message
news:dFALb.7634$xy6.17977@.attbi_s02...
Is there any easy way to create a change script as illustrated below for all
tables within a database?

Right now I would have to create a seperate script for each table.

I would like to be able to update the customers database while preserving
their exisiting data.

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
CREATE TABLE dbo.Tmp_Deposits
(
DEPSYSID int NOT NULL IDENTITY (1, 1),
DEPBANKID int NULL,
DEPUSER varchar(50) NULL,
DEPSTATUS tinyint NULL,
CHECKORCASH varchar(10) NULL,
CHECKNUMBER varchar(10) NULL,
DEPOSITSOURCE varchar(50) NULL,
DEPAMOUNT decimal(9, 2) NULL,
CASHDRAWERID int NULL,
DEPOSITDATE datetime NULL,
ACTUALDEPOSITUSER varchar(50) NULL,
ACTUALDEPOSITDATE datetime NULL
) ON [PRIMARY]
GO
SET IDENTITY_INSERT dbo.Tmp_Deposits ON
GO
IF EXISTS(SELECT * FROM dbo.Deposits)
EXEC('INSERT INTO dbo.Tmp_Deposits (DEPSYSID, DEPBANKID, DEPUSER,
DEPSTATUS, CHECKORCASH, CHECKNUMBER, DEPOSITSOURCE, DEPAMOUNT, CASHDRAWERID,
DEPOSITDATE, ACTUALDEPOSITUSER, ACTUALDEPOSITDATE)
SELECT DEPSYSID, DEPBANKID, DEPUSER, DEPSTATUS, CHECKORCASH, CHECKNUMBER,
DEPOSITSOURCE, DEPAMOUNT, CASHDRAWERID, DEPOSITDATE, ACTUALDEPOSITUSER,
ACTUALDEPOSITDATE FROM dbo.Deposits TABLOCKX')
GO
SET IDENTITY_INSERT dbo.Tmp_Deposits OFF
GO
DROP TABLE dbo.Deposits
GO
EXECUTE sp_rename N'dbo.Tmp_Deposits', N'Deposits', 'OBJECT'
GO
ALTER TABLE dbo.Deposits ADD CONSTRAINT
DEP_SYSID PRIMARY KEY CLUSTERED
(
DEPSYSID
) ON [PRIMARY]

GO
CREATE NONCLUSTERED INDEX DEP_STATUS ON dbo.Deposits
(
DEPSTATUS
) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX DEP_Date ON dbo.Deposits
(
DEPOSITDATE
) ON [PRIMARY]
GO
COMMIT

--
Tim Morrison

-----------------------
--

Vehicle Web Studio - The easiest way to create and maintain your vehicle
related website.
http://www.vehiclewebstudio.com|||The problem is that this is a commercial application. Say my initial
database I call version 1000, then I make some changes, then version 1001
then version 1002, etc.

When I send an update, some users may have 1000, some 1001, etc.

If I have a change script for all tables, then it doesent matter what
version they have.

Tim

"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:btna9g$o8$1@.sparta.btinternet.com...
> Hi
> In general this task would not be needed if you kept the database objects
in
> a source code control system. You can do it by comparing two different
> databases (pre changes and post changes) and compare the system schemas
> using three part naming convensions and cursors.
> Alternatively get something like red gate compare http://www.red-gate.com
to
> do it for you. This question does get asked quite frequently in the news
> groups so you may want to check Google for other solutions.
> It may also be possible to do this from VISIO if you are modelling the
> database.
> John
> "Tim Morrison" <sales@.kjmsoftware.com> wrote in message
> news:dFALb.7634$xy6.17977@.attbi_s02...
> Is there any easy way to create a change script as illustrated below for
all
> tables within a database?
> Right now I would have to create a seperate script for each table.
> I would like to be able to update the customers database while preserving
> their exisiting data.
>
>
> 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
> CREATE TABLE dbo.Tmp_Deposits
> (
> DEPSYSID int NOT NULL IDENTITY (1, 1),
> DEPBANKID int NULL,
> DEPUSER varchar(50) NULL,
> DEPSTATUS tinyint NULL,
> CHECKORCASH varchar(10) NULL,
> CHECKNUMBER varchar(10) NULL,
> DEPOSITSOURCE varchar(50) NULL,
> DEPAMOUNT decimal(9, 2) NULL,
> CASHDRAWERID int NULL,
> DEPOSITDATE datetime NULL,
> ACTUALDEPOSITUSER varchar(50) NULL,
> ACTUALDEPOSITDATE datetime NULL
> ) ON [PRIMARY]
> GO
> SET IDENTITY_INSERT dbo.Tmp_Deposits ON
> GO
> IF EXISTS(SELECT * FROM dbo.Deposits)
> EXEC('INSERT INTO dbo.Tmp_Deposits (DEPSYSID, DEPBANKID, DEPUSER,
> DEPSTATUS, CHECKORCASH, CHECKNUMBER, DEPOSITSOURCE, DEPAMOUNT,
CASHDRAWERID,
> DEPOSITDATE, ACTUALDEPOSITUSER, ACTUALDEPOSITDATE)
> SELECT DEPSYSID, DEPBANKID, DEPUSER, DEPSTATUS, CHECKORCASH,
CHECKNUMBER,
> DEPOSITSOURCE, DEPAMOUNT, CASHDRAWERID, DEPOSITDATE, ACTUALDEPOSITUSER,
> ACTUALDEPOSITDATE FROM dbo.Deposits TABLOCKX')
> GO
> SET IDENTITY_INSERT dbo.Tmp_Deposits OFF
> GO
> DROP TABLE dbo.Deposits
> GO
> EXECUTE sp_rename N'dbo.Tmp_Deposits', N'Deposits', 'OBJECT'
> GO
> ALTER TABLE dbo.Deposits ADD CONSTRAINT
> DEP_SYSID PRIMARY KEY CLUSTERED
> (
> DEPSYSID
> ) ON [PRIMARY]
> GO
> CREATE NONCLUSTERED INDEX DEP_STATUS ON dbo.Deposits
> (
> DEPSTATUS
> ) ON [PRIMARY]
> GO
> CREATE NONCLUSTERED INDEX DEP_Date ON dbo.Deposits
> (
> DEPOSITDATE
> ) ON [PRIMARY]
> GO
> COMMIT
>
>
> --
> Tim Morrison
> -----------------------
--
> --
> Vehicle Web Studio - The easiest way to create and maintain your vehicle
> related website.
> http://www.vehiclewebstudio.com|||Hi

This is not the case, the script to change from version 1 to version 2 is
not necessarily the same as the script to change from version 1 to version
3. You can either have two scripts version 1 to version 2 and version 2 to
version 3, which will mean fewer scripts but potentially longer
installations. Alternatively you can have one for each combination of
versions, which will quicker installations but will soon become unmanagable.
Another alternative you can write/buy a tool/process which compares a
specific version (call it a template database) with what is currently in
production, this is fine until you want to do something that is not
"standard"! e.g split a column or table into two different ones, you will
then have resorted to the first solution!

John

"Tim Morrison" <sales@.kjmsoftware.com> wrote in message
news:DtGLb.9796$xy6.22683@.attbi_s02...
> The problem is that this is a commercial application. Say my initial
> database I call version 1000, then I make some changes, then version 1001
> then version 1002, etc.
> When I send an update, some users may have 1000, some 1001, etc.
> If I have a change script for all tables, then it doesent matter what
> version they have.
> Tim
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:btna9g$o8$1@.sparta.btinternet.com...
> > Hi
> > In general this task would not be needed if you kept the database
objects
> in
> > a source code control system. You can do it by comparing two different
> > databases (pre changes and post changes) and compare the system schemas
> > using three part naming convensions and cursors.
> > Alternatively get something like red gate compare
http://www.red-gate.com
> to
> > do it for you. This question does get asked quite frequently in the news
> > groups so you may want to check Google for other solutions.
> > It may also be possible to do this from VISIO if you are modelling the
> > database.
> > John
> > "Tim Morrison" <sales@.kjmsoftware.com> wrote in message
> > news:dFALb.7634$xy6.17977@.attbi_s02...
> > Is there any easy way to create a change script as illustrated below for
> all
> > tables within a database?
> > Right now I would have to create a seperate script for each table.
> > I would like to be able to update the customers database while
preserving
> > their exisiting data.
> > 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
> > CREATE TABLE dbo.Tmp_Deposits
> > (
> > DEPSYSID int NOT NULL IDENTITY (1, 1),
> > DEPBANKID int NULL,
> > DEPUSER varchar(50) NULL,
> > DEPSTATUS tinyint NULL,
> > CHECKORCASH varchar(10) NULL,
> > CHECKNUMBER varchar(10) NULL,
> > DEPOSITSOURCE varchar(50) NULL,
> > DEPAMOUNT decimal(9, 2) NULL,
> > CASHDRAWERID int NULL,
> > DEPOSITDATE datetime NULL,
> > ACTUALDEPOSITUSER varchar(50) NULL,
> > ACTUALDEPOSITDATE datetime NULL
> > ) ON [PRIMARY]
> > GO
> > SET IDENTITY_INSERT dbo.Tmp_Deposits ON
> > GO
> > IF EXISTS(SELECT * FROM dbo.Deposits)
> > EXEC('INSERT INTO dbo.Tmp_Deposits (DEPSYSID, DEPBANKID, DEPUSER,
> > DEPSTATUS, CHECKORCASH, CHECKNUMBER, DEPOSITSOURCE, DEPAMOUNT,
> CASHDRAWERID,
> > DEPOSITDATE, ACTUALDEPOSITUSER, ACTUALDEPOSITDATE)
> > SELECT DEPSYSID, DEPBANKID, DEPUSER, DEPSTATUS, CHECKORCASH,
> CHECKNUMBER,
> > DEPOSITSOURCE, DEPAMOUNT, CASHDRAWERID, DEPOSITDATE, ACTUALDEPOSITUSER,
> > ACTUALDEPOSITDATE FROM dbo.Deposits TABLOCKX')
> > GO
> > SET IDENTITY_INSERT dbo.Tmp_Deposits OFF
> > GO
> > DROP TABLE dbo.Deposits
> > GO
> > EXECUTE sp_rename N'dbo.Tmp_Deposits', N'Deposits', 'OBJECT'
> > GO
> > ALTER TABLE dbo.Deposits ADD CONSTRAINT
> > DEP_SYSID PRIMARY KEY CLUSTERED
> > (
> > DEPSYSID
> > ) ON [PRIMARY]
> > GO
> > CREATE NONCLUSTERED INDEX DEP_STATUS ON dbo.Deposits
> > (
> > DEPSTATUS
> > ) ON [PRIMARY]
> > GO
> > CREATE NONCLUSTERED INDEX DEP_Date ON dbo.Deposits
> > (
> > DEPOSITDATE
> > ) ON [PRIMARY]
> > GO
> > COMMIT
> > --
> > Tim Morrison
> -----------------------
> --
> > --
> > Vehicle Web Studio - The easiest way to create and maintain your vehicle
> > related website.
> > http://www.vehiclewebstudio.com|||Tim Morrison (sales@.kjmsoftware.com) writes:
> The problem is that this is a commercial application. Say my initial
> database I call version 1000, then I make some changes, then version 1001
> then version 1002, etc.
> When I send an update, some users may have 1000, some 1001, etc.
> If I have a change script for all tables, then it doesent matter what
> version they have.

Maybe. It depends on how wild your changes are.

I may have some experience to share, as I work in a company that develop
a commercial application, and I am responsible for data model for the
core part of the database. So I have written a few change scripts...

First, as John said, instrumental is to use a version-control system.
Since you are developing an application which you distribute commercially,
this is an absolute must.

I generate my change script with a tool, DBUPDGEN, that I have written
myself. (Available as freeware on http://www.abaris.se/abaperls/.) DBUPDGEN
reads the contents of two SourceSafe labels, and generate an update script
in Perl with instructions to read all changed objects from SourceSafe or
disk and load them in the database. You can feed DBUPDGEN an existing
script, and it will update the script. This is good if you set a new label.
DBUPDGEN still permits manual changes to the script.

For changed tables, it produces a template which works if all I've done is
to add a column which accepts NULL or a default value, but for other
changes I have to change the template. The philosophy is that a tool can
not understand all complicated changes anyway, so I found no reason to
spend time on making it smart.

I should add that the template works by renaming the old table, creating
the new table and then copy the data. Partly, this is due to legacy; the
tool is from SQL 6.0 days, but also I think column order is important when
I look at SELECT * queries in Query Analyzer.

The tool uses its internal system tables, so that it can verify that an
update script is permissible. If you try to load a script that is supposed
to upgrade the database from 7.10.0001 to 7.10.0212, but the current
database is at 6.20.0230 you will get an error.

As for the case that a customer may need to move several versions at
one time, we don't have any handling for this. If a customer moves from
6.20 to 7.30, we will have to run the update scripts for 7.10, 7.20 and
7.30, even if this means reloading the same big table more than once.

Leaving my own tool behind, there are probably quite a few third-party
tools out there, that can generate update scripts for. John mentioned SQL
Compare, which works from databases. I would expect that all the major
data-modelling tools - PowerDesigner, ErWin and Embrocadero - has such a
feature. (I use PowerDesigner, and I know that it has this feature,
although I don't use it.)

Lately, I have seen several promotional postings for a couple of
version-control systems, specifically aimed at SQL stuff. Some are
probably add-ons to Visual SourceSafe (Microsoft's low-budget alternative
to version-control), while others may use their own database. I don't
have any names handy, but a Google search should find a few.

Whichever way you go, you will need to invest some time to learn the
tool you choose, and to understand the process. Configuration Management
is no easy task to get started with, but once you have a robust process,
you are on safe ground.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thanks for the post...

In my case, the changes are not drastic. In most cases, the SQL database is
automatically updated via the development environment I use (Clarion) which
handles MOST changes, like adding tables, modifying fields (CHAR(10) to
CHAR(11), etc).

The reason this came up is I had a table that did not have the IDENTITY
parameter set on my PK, which is one issue that is not automatically set. So
the idea of using change scripts came to mind. This way I can send one
script that will both create the tables if they dont exist and update the
tables if they do exist.

Tim Morrison

"Erland Sommarskog" <sommar@.algonet.se> wrote in message
news:Xns946D1FE6C8DAYazorman@.127.0.0.1...
> Tim Morrison (sales@.kjmsoftware.com) writes:
> > The problem is that this is a commercial application. Say my initial
> > database I call version 1000, then I make some changes, then version
1001
> > then version 1002, etc.
> > When I send an update, some users may have 1000, some 1001, etc.
> > If I have a change script for all tables, then it doesent matter what
> > version they have.
> Maybe. It depends on how wild your changes are.
> I may have some experience to share, as I work in a company that develop
> a commercial application, and I am responsible for data model for the
> core part of the database. So I have written a few change scripts...
> First, as John said, instrumental is to use a version-control system.
> Since you are developing an application which you distribute commercially,
> this is an absolute must.
> I generate my change script with a tool, DBUPDGEN, that I have written
> myself. (Available as freeware on http://www.abaris.se/abaperls/.)
DBUPDGEN
> reads the contents of two SourceSafe labels, and generate an update script
> in Perl with instructions to read all changed objects from SourceSafe or
> disk and load them in the database. You can feed DBUPDGEN an existing
> script, and it will update the script. This is good if you set a new
label.
> DBUPDGEN still permits manual changes to the script.
> For changed tables, it produces a template which works if all I've done is
> to add a column which accepts NULL or a default value, but for other
> changes I have to change the template. The philosophy is that a tool can
> not understand all complicated changes anyway, so I found no reason to
> spend time on making it smart.
> I should add that the template works by renaming the old table, creating
> the new table and then copy the data. Partly, this is due to legacy; the
> tool is from SQL 6.0 days, but also I think column order is important when
> I look at SELECT * queries in Query Analyzer.
> The tool uses its internal system tables, so that it can verify that an
> update script is permissible. If you try to load a script that is supposed
> to upgrade the database from 7.10.0001 to 7.10.0212, but the current
> database is at 6.20.0230 you will get an error.
> As for the case that a customer may need to move several versions at
> one time, we don't have any handling for this. If a customer moves from
> 6.20 to 7.30, we will have to run the update scripts for 7.10, 7.20 and
> 7.30, even if this means reloading the same big table more than once.
> Leaving my own tool behind, there are probably quite a few third-party
> tools out there, that can generate update scripts for. John mentioned SQL
> Compare, which works from databases. I would expect that all the major
> data-modelling tools - PowerDesigner, ErWin and Embrocadero - has such a
> feature. (I use PowerDesigner, and I know that it has this feature,
> although I don't use it.)
> Lately, I have seen several promotional postings for a couple of
> version-control systems, specifically aimed at SQL stuff. Some are
> probably add-ons to Visual SourceSafe (Microsoft's low-budget alternative
> to version-control), while others may use their own database. I don't
> have any names handy, but a Google search should find a few.
> Whichever way you go, you will need to invest some time to learn the
> tool you choose, and to understand the process. Configuration Management
> is no easy task to get started with, but once you have a robust process,
> you are on safe ground.
> --
> Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../2000/books.asp