This is a discussion on Script Question within the SQL Server forums, part of the Microsoft SQL Server category; --> Is there any easy way to create a change script as illustrated below for all tables within a database? ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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 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 > 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/techinf...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/techinf...2000/books.asp |
| Thread Tools | |
| Display Modes | |
|
|