Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

Authors

Search

XML Feeds

Google Ads

« How to copy data/append data into files from within T-SQLDynamic column names and fields in SSRS (Custom Matrix) »
comments
Rate Post:
submit to reddit Digg!FacebookDotnetkicks

I've seen this question numerous times in the forums I like to frequent. The idea is, when you create a new database, you may want that database to have several tables, some of which are automatically populated with data (thinking about relatively static lookup tables here).

The process mentioned here may not be useful for everyone, but it is certainly something to consider.

There is a system database named Model. This database is used when you create a new user database. In fact, any object (table, view, stored procedures, functions, etc…) that exists in the model database will be copied to your newly created database. This may be a blessing and a curse, so use this suggestion wisely. If you have a SQL Instance where you need to set up a new database for each customer, and that is all the instance is used for, then it makes sense to create your objects in the Model database. However, if you have a general purpose instance that you are using for various databases, you probably won’t want to put your objects in the Model database.

Enough of the chatter, let's see how this can be done.

First, create a table in the Model database.

  1. USE Model
  2. go
  3.  
  4. CREATE TABLE TestAutoDBCreation(Id INT, Color VARCHAR(20))
  5. INSERT INTO TestAutoDBCreation VALUES(1, 'Red')
  6. INSERT INTO TestAutoDBCreation VALUES(2, 'Blue')

Now, let’s create a new database.

  1. USE Master
  2. go
  3. CREATE DATABASE NewDatabaseWithModelTable

Now, let's make sure the table (and it's data) exist in the new database.

  1. USE NewDatabaseWithModelTable
  2. go
  3. SELECT * FROM TestAutoDBCreation

As you can see, the table that was created in Model exists in the newly created database. It even has all the data that was loaded in to it.

Now, let’s clean up after ourselves:

  1. USE Model
  2. go
  3. DROP TABLE TestAutoDBCreation
  4. go
  5. USE Master
  6. go
  7. DROP DATABASE NewDatabaseWithModelTable

About the Author

George has been developing software professionally for 19 years, first for the department of defense, and then for various other companies. In 1998, George started his software company, Orbit Software, specializing in School Bus Transportation software. His specialty is refining SQL Server queries to deliver optimal performance.
Social SitingsTwitterLTD RSS Feed
1664 views
submit to reddit Digg!FacebookDotnetkicks

Comments and Feedback

2 comments

Comment from: SQLDenis [Member] Email
*****
This is also handy if you want to have a bunch of procs in every database
07/03/09 @ 11:49
Comment from: Naomi [Member] Email
*****
Thanks, this is very useful.
07/03/09 @ 12:01

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)