Tag Archives: ssms


SSMS: Script a table and its rows

SQL Server Management Studio provides the means to not only create a table to a script editor window, but to script its rows.

This tip is really handy if you’ve ever needed to copy a table from one database to another, or maybe if you’ve needed to script both a table and its rows to the DDL/Schema part of an SQLFiddle.

Here’s how:-

  1. Right click on your database in Object Explorer, and choose Tasks > Generate Scripts.Step1
  2. From the dialog, choose ‘Select specific database objects, expand the tables view and put a check in the table (or tables) you want to script.  Click Next when done.
  3. Select ‘Save to new query window’, and then click the ‘Advanced’ button in the top right hand corner.
  4. There’s a lot of options here that I might cover at another time, but for now you just need to find the ‘Types of data to script’ line (which is by default set to ‘Schema only’), and set it to ‘Schema and Data’ (this will ensure you get the DDL for the table as well as the insert statements you need to populate it.
  5. Now click OK, Next and Next again and wait for the wizard to generate your script.
  6. When done, the full script should be available in your Query Editor window.

Handy stuff, isn’t it?  Like I said, there are a load more options in the ‘Advanced’ dialog (such as choosing whether you want to add DROP table statements, extended properties, primary keys etc).  I’ll perhaps cover these and what they do in my next post, but why not have a click around and see what they do yourself?


SSMS Quick Tip: Highlight errors in the SQL editor window

You’re more than likely familiar with this kind of error in the ‘Messages’ window in SSMS:-

Msg 156, Level 15, State 1, Line 7
Incorrect syntax near the keyword 'from'.

Did you know that, if you double-click the error, the line of code that generated that error is highlighted in the editor window?  I only discovered this today, and already it’s something I’m using regularly.  Can’t believe I wasn’t aware of it before today.


Using temporary tables in SQL Server

In this article I’d like to discuss temporary tables and their usage in SQL Server. I’m going to discuss the reasons for their use and a few ways that they can be implemented in your database development efforts. Hopefully you’ll find them to be an invaluable weapon in your SQL armory.

What are temporary tables?

The clue’s in the name, really.  Temporary tables are often used to store data whilst you are carrying out some kind of transform or other processing on existing table data. Very often I use temporary tables to store information that might eventually find its way into another table whilst I’m updating it.  It’s also handy to use them whilst just playing around with your data, almost like a sandbox of sorts.

If they are just temporary, how (and where) are they stored?

All temporary databases are stored in the ‘tempdb’ database, which can be found in Databases > System Databases > tempdb in the Object Explorer in SSMS.

object explorer

Depending on the kind of temporary table created, they will exist in tempdb in a different location, and for a different length of time.

How do they work?  How long do these tables stick around if they are temporary?

Good question.  There are actually three ways of creating and using temporary tables in the tempdb database, and the way you create them has a different effect on how long they can be used for (and who/what they can be used by).

Let’s have a look at the three methods of creating temporary tables and talk about them in more detail.

1. Local temporary tables

A local temporary table is created in TSQL like this.  I’ll also populate with a row of data, just for you.

CREATE TABLE #MyTable(ID int, Value varchar(10))

Notice the single hashtag (nothing to do with Twitter, this).  This tells the database that we want to create a temporary table that is local to this particular session, in this particular case the T-SQL editor window that we are working in.

A temporary table created with a single hashtag isn’t accessible by anybody else or any other process.  The second the process that created it is closed, the table disappears completely.  Forever.

To prove this point, open a New Query and copy the SQL statement above into it.  Press F5 to  create and populate the temporary table, and then run the following simple SELECT in the same window to see if it worked ok :


If you’ve been following along, you should get the single row of data that we added earlier.

Now, open a New Query window and try the same SELECT statement:-

invalid object

This shouldn’t come as a surprise based on what I said earlier – the only process that can access the #MyTable object is the one that created it (the first query window you opened earlier).

If you close the query window containing the CREATE TABLE statement you will now no longer be able to access the temporary table you created.  It is gone.  Forever.

2.  Global Temporary Tables

Global temporary tables are pretty much the same to set as local, except you use two hashtags instead of two!  The main difference between global temporary tables is that they are available for use by anybody, not just the process that created them.

Let me show you what I mean.

Close all query editor windows , and then open a new one.  Copy the following:-

CREATE TABLE ##MyTable(ID int, Value varchar(10))

And press F5 to run it.  If you write a simple SELECT:-


You’ll notice  (hopefully unsurprisingly) that the table is (obviously) accessible.

Now (here’s the magic bit) open a second New Query and try the same select statement.

Global Temp Table

Perfect!  This temporary table is available to anything else that wants to use it, as long as the process that created it is still active. To demonstrate what I mean by this, close the query editor window where we created the temporary table and try to run the SELECT statement again.

Global Table Fail

And it’s gone.  Forever.  Again.

3.  Create a table in tempdb

You can create a table in tempdb in the same way as you would any other database:-

USE tempdb
CREATE TABLE  MyTable(ID int, Value varchar(10))

If you refresh the ‘Tables’ folder in Object Explorer, you’ll see our newly created table:-

object explorer temp

This table behaves like any other table in the database at this stage.  Any database user or process can access it, and it continues to act as a persistent database object (like any other).

Any table created in tempdb exists until the server is restarted or the table itself is dropped. Restarting the server will clear out any temporary tables created in the tempdb database and essentially recreate tempdb from scratch. This makes tempdb an ideal sandbox for playing around (just don’t rely on objects created in it being around forever!!).


The use of temporary tables is, I think, one of the more useful techniques in TSQL.  I use them quite often for ETL style processes, for example Create a temporary table > Load data into it > Manipulate/transform data > Do something with the output (perhaps INSERT INTO another table), but they can be put to use in so many different ways, and are really straightforward to put into practice.

Have fun!