When I try to script a table CREATE from a database, it doesn't always script all the columns inside a single CREATE TABLE. Some of the columns will be added via ALTER TABLEs. Why is this? Is SQL server capturing the history of the schema modifications, and any columns added after the initial creation are scripted with ALTERS? The reason this matters is because I'm scripting tables to be used within a VS Database project and it can't handle the ALTER statements.
CREATE TABLE [dbo].[tblPackageType]
(
[PackageTypeId] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
[PackageTypeDesc] [varchar](50) NOT NULL
) ON [PRIMARY]
ALTER TABLE [dbo].[tblPackageType] ADD [EDIcode] [varchar](10) NOT NULL
ALTER TABLE [dbo].[tblPackageType] ADD [EDI211] [varchar](10) NULL
Is SQL server capturing the history of the schema modifications, and any columns added after the initial creation are scripted with ALTERS?
Yes.
If you want to get around this, you can alter the script to be a create including all the needed columns, and after you run it the updated definition will be saved.
Related
After rebuilding all of the tables in one of my SQL SERVER databases, into a new database, I failed to set the 'ID' column to IDENTITY and PRIMARY KEY for many of the tables. Most of them have data.
I discovered this T-SQL, and have successfully implemented it for a couple of the tables already. The new/replaced ID column contains the same values from the previous column (simply because they were from an auto-incremented column in the table I imported from), and my existing stored procedures all still work.
Alter Table ExistingTable
Add NewID Int Identity(1, 1)
Go
Alter Table ExistingTable Drop Column ID
Go
Exec sp_rename 'ExistingTable.NewID', 'ID', 'Column'
--Then open the table in Design View, and set the new/replaced column as the PRIMARY KEY
--I understand that I could set the PK when I create the new IDENTITY column
The new/replaced ID column is now the last column in the table, and so far, I haven't ran into issues with the ASP.Net/C# data access objects that call the stored procedures.
As mentioned, each of these tables had no PRIMARY KEY (nor FOREIGN KEY) set. With that in mind, are there any additional steps I should take to ensure the integrity of the database?
I ran across this SO post, which suggests that I should run the 'ALTER TABLE REBUILD' statement, but since there was no PK already set, do I really need to do this?
Ultimately, I just want to be sure I'm not creating issues that won't appear until later in the game, and be sure the methods I'm implementing are sound, logical, and ensure data integrity.
I suppose it might be a better option to DROP/RECREATE the table with the proper PK/IDENTITY column, and I could write some T-SQL to dump the existing data into a TEMP table, then drop/recreate, and re-populate the new table with data from the TEMP table. I specifically avoided this option as it seems much more aggressive, and I don't fully understand what it means for the Stored Procedures/Functions, etc., that depend on these tables.
Here is an example of one of the tables I've performed this on. You can see the NewID values are identical to the original ID.enter image description here
Give this a go; it's rummaged up from a script we used a few years ago in a similar situation, can't remember what version of SQLS it was used against.. If it works out for your scenario you can adapt it to your tables..
SELECT MAX(Id)+1 FROM causeCodes -- run and use value below
CREATE TABLE [dbo].[CauseCodesW]( [ID] [int] NOT NULL IDENTITY(put_maxplusone_here,1), [Code] [varchar](50) NOT NULL, [Description] [varchar](500) NULL, [IsActive] [bit] NOT NULL )
ALTER TABLE CauseCodes SWITCH TO CauseCodesW;
DROP TABLE CauseCodes;
EXEC sp_rename 'CauseCodesW','CauseCodes';
ALTER TABLE CauseCodes ADD CONSTRAINT PK_CauseCodes_Id PRIMARY KEY CLUSTERED (Id);
SELECT * FROM CauseCodes;
You can now find any tables that have FKs to this table and recreate those relationships..
The creation of a SQL Server External Table requires remote tables to be made accessible by running code of the following format on the local database:
CREATE EXTERNAL TABLE [TABLE_NAME]
(
[Id] [int] NOT NULL,
[Name] [int] NULL,
)
WITH (DATA_SOURCE = [EXTERNAL_DB_NAME])
I have a quite a few external tables to work with, and am wondering if this functionality can be automated. So, is there a way to create the text for a CREATE TABLE statement from the Information Schema views on the remote database ? This could then be altered and used to populate a dynamic query to be run on the local database.
I have a table in a production server which occasionally has mysterious data occur in it. Is it possible to track the history of adding data to the table to find out why/who/when...? I am reluctant to put a trigger on the table (and it would only help for future checking) because the data volume is usually huge and this might affect performance.
I only have db-owner privilege, not sa privilege.
You can use a default value in a new column and save there the user name with SUSER_SNAME().
Example
CREATE TABLE [dbo].[Table_1](
[id] [INT] NULL,
[name] [NCHAR](100) NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Table_1] ADD CONSTRAINT [DF_Table_1_name] DEFAULT (SUSER_SNAME()) FOR [name]
GO
I have already tried to alter the user defined table types but it is not working with alter commend.
alter TYPE [dbo].[GriDDateTab] AS TABLE(
[Application [varchar](50) NOT NULL,
[LandDist] [char](2) NULL,
[Land] [char](3) NULL,
[LandVi] [char](4) NULL)
You have to drop and recreate. That means if you have any references (eg stored procedures) using the type, that reference must be removed first.
The bad news is that you have to drop and re-create as SQL server does not (at least not up until 2012 support this.
The good news is that stored procedures and functions should pick up table type changes on the fly with no need to drop and re-create.
Sadly everything said is true, however you can save yourself some time by by going to the context menu of the table type->Script User-Defined Table Type as..
If you use DROP and CREATE To Query Window you can make your edits and click execute.
You will still have to recreate references in other Programmability structures.
I am using a SQL Server 2008 database.
I have two databases namely db1 and db2. In both there is a table tblcountry. I create this on 1st database. Then how can I script with its data for create on 2nd database?
I use the code below
CREATE TABLE [dbo].[tblCountry]
(
[record_Id] [int] IDENTITY(1,1) NOT NULL,
[country] [nvarchar](150) NULL,
[nationality] [nvarchar](150) NULL,
[lsdMdfdOn] [datetime] NULL,
[lstMdfdBy] [nvarchar](350) NULL,
[isDeleted] [bit] NULL,
[isEnabled] [bit] NULL,
)
Then what code will I use for the getting include the data?
No, you cannot view the data if you are using the create query.
If you want to see the data of the table on second database then you can use this query on your second database db2
select * from [db1].[dbo].[tblCountry]
But you can not view the data and create query at the same time.
Although it may seem very wierd solution but I guess what you can do is you can copy the create query on the query analyzer window and beneath that write the select query and execute it. (But I guess this is how most of the programmers do that)
If you are on the same server or have a linked server:
CREATE TABLE tblCountry
SET IDENTITY_INSERT tblCountry ON
INSERT INTO [database2].tblCountry
SELECT * FROM [database1].tblCountry
SET IDENTITY_INSERT tblCountry OFF
The most Easy way for this problem is for you to
Right Click on the Database on the Object Explorer
click Generate Scripts
on the introduction click Next
Select radio button on Script entire database and all database
objects or you can just select specific tables or stored
procedures by selecting the other radio button
On the Set Scripting Options click on Advanced Select the things you
want to script
Then on the Query just change the database name after the query USE
db2
Right click on database and click on tasks and export data
you can use export data option in sql server...it will give you data with table script