Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 New to SQL Server Programming
 how do I dynamically build create table statements

Author  Topic 

Bjcascone
Starting Member

37 Posts

Posted - 2011-03-01 : 16:16:43
I am attempting to create a new table (basically a copy of an existing one just changing the name) in a new DB. I am trying to do this by recursing through a list of existing table names and build each table on (all fields are the same) I know there are a few ways to do this but i am having trouble getting this to work as a recursive loop that builds the statement and populates the table names each time it executes. this is what i have so far:


(this gives me my unique list of names i will later use to populate the query)-- SELECT TABLE NAMES WITH ONLY NUMERIC NAMES INTO NEW TABLE.

BEGIN
SET @SQLStringTBL = "
BEGIN TRY
DROP TABLE " + @DBNAME + ".DBO.TBLNAMELIST
END TRY
BEGIN CATCH
END CATCH
SELECT [NAME] AS [NAME] INTO " + @DBName + " .DBO.TBLNAMELIST FROM " + @DBName + " .DBO.sysobjects
WHERE isnumeric([Name])=1 "
EXEC(@SQLStringTBL)
END




(this is where I am having issues. The @TBLNAME variable only exists in the @SQL and that is where it is being initialized.)
SET @SQL = "

DECLARE @TBLNAME AS VARCHAR(100)
DECLARE TBLNM CURSOR FOR
SELECT [NAME] FROM " + @NEWDBNAME+".DBO.TBLNAMELIST

OPEN TBLNM
FETCH NEXT FROM " + @NEWDBNAME+".DBO.TBLNAMELIST INTO "+ @TBLNAME + "

WHILE @@FETCH_STATUS = 0

BEGIN
BEGIN TRY
DROP TABLE " + @NEWDBNAME+".DBO.TEMPdbname
END TRY
BEGIN CATCH
END CATCH

USE " + @NEWDBNAME+" GO
SET ANSI_NULLS ON GO
SET QUOTED_IDENTIFIER ON GO
SET ANSI_PADDING ON GO

CREATE TABLE [dbo]. a"+ @TBLNAME +" (
[Dept] [smallint] NULL,
[Class] [smallint] NULL,
[Item] [smallint] NULL,
[Store] [smallint] NULL,
[Year] [smallint] NULL,
[Monthh] [smallint] NULL,
[OHQty1] [int] NULL,
[SalesQty1] [int] NULL,
[SalesAmt1] [money] NULL,
[OHQty2] [int] NULL,
[SalesQty2] [int] NULL,
[SalesAmt2] [money] NULL,
[OHQty3] [int] NULL,
[SalesQty3] [int] NULL,
[SalesAmt3] [money] NULL,
[OHQty4] [int] NULL,
[SalesQty4] [int] NULL,
[SalesAmt4] [money] NULL,
[OHQty5] [int] NULL,
[SalesQty5] [int] NULL,
[SalesAmt5] [money] NULL,
[RetlAmt1] [money] NULL,
[GrossRnchk1] [money] NULL,
[RnchkSub1] [int] NULL,
[AdRetl1] [money] NULL,
[RetlAmt2] [money] NULL,
[GrossRnchk2] [money] NULL,
[RnchkSub2] [int] NULL,
[AdRetl2] [money] NULL,
[RetlAmt3] [money] NULL,
[GrossRnchk3] [money] NULL,
[RnchkSub3] [int] NULL,
[AdRetl3] [money] NULL,
[RetlAmt4] [money] NULL,
[GrossRnchk4] [money] NULL,
[RnchkSub4] [int] NULL,
[AdRetl4] [money] NULL,
[RetlAmt5] [money] NULL,
[GrossRnchk5] [money] NULL,
[RnchkSub5] [int] NULL,
[Adretl5] [money] NULL,
[SalesType1] [char](1) NULL,
[SalesType2] [char](1) NULL,
[SalesType3] [char](1) NULL,
[SalesType4] [char](1) NULL,
[SalesType5] [char](1) NULL,
[VenNum] [real] NULL,
[InvRcvQty] [real] NULL,
[TermsDiscAmt] [float] NULL,
[NetMkdnAmtA] [float] NULL,
[NetMkdnAmtB] [float] NULL,
[NetMkdnAmtC] [float] NULL,
[NetMkdnAmtD] [float] NULL,
[MkUAmt] [float] NULL,
[MkupCanAmt] [float] NULL,
[CbVendIncmAmt] [float] NULL,
[CBDefectCostAmt] [float] NULL,
[CBMiscCostAmt] [float] NULL,
[InBndFrtAmt] [float] NULL,
[OutBndFrtAmt] [float] NULL,
[MiscFrtAmt] [float] NULL,
[StoreCrcFrtAmt] [float] NULL,
[CrcVendFrtAmt] [float] NULL
) ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO


CLOSE TBLNM
DEALLOCATE TBLNM
END
"


PRINT(@SQL)



Thank you for any help you are able to provide.

-Brian

robvolk
Most Valuable Yak

15732 Posts

Posted - 2011-03-01 : 16:34:32
Why not just generate scripts for the existing tables and run them in the new database? Right-click the database in SSMS, Tasks, Generate Scripts, and go from there.
Go to Top of Page

Bjcascone
Starting Member

37 Posts

Posted - 2011-03-01 : 16:41:08
These tables are going to get recreated on a monthly basis and the names are going to change each time.. for example:

DB01
TableXX01
TableXX02
TableXX03
TableXX04

the next month the same thing will have to get done
DB01
TableYY01
TableYY02
TableYY03
TableYY04

Also this is part of a much larger stored proc that ultimatly is inserting the data in these tables into a new database in identical compressed tables, and makes some name changes.



Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2011-03-01 : 16:59:24
Should I bother mentioning this is a poor design practice? Identical table structures should have their data consolidated into a single table of the proper structure. Doing so avoids the entire need for this procedure.
Go to Top of Page

Bjcascone
Starting Member

37 Posts

Posted - 2011-03-01 : 17:18:52
I do not work in a transactional environment it is more of a development enviorment in a data warehouse. I am doing this because the data in this DB is rather large (over 1TB, and there are 12 of them, one for every month they are partitioned) due to the sheer size of these tables they are basically "stored" as compressed tables. but running the compression and shrinking the DB after takes a long time. so the procedure that i am writing creates a new DB, creates the tables, turns on the compression on these new tables, does a minimally logged insert into these new tables (space savings of 75%) and eventually drops the old tables and DB. This may not be the best way to go about this but currently shrinking these compated DB's are taking 22 days and this new method will take less than a day. I am just trying to automate these steps into a single Stored procedure.
Go to Top of Page

robvolk
Most Valuable Yak

15732 Posts

Posted - 2011-03-01 : 17:25:15
Then why not consolidate your uncompressed DBs into a single compressed database? All you have to do is run INSERTs from the old into the new. You don't have to recreate a new DB and go through the entire compression process for each one, and you reduce the number of databases. The amount of disk space used in the end will be the same, perhaps even less.

By the way, unless you are damn near out of disk space, DO NOT SHRINK your databases. You'll fragment the data and indexes and lower performance.
Go to Top of Page
   

- Advertisement -