"Should I use Variables, Parameters, or Literals in my code?" We've all seen the pros and cons for each of them and had to choose the option with the least negative impact. What if I told you there was a fourth option?

For years, I wished SQL Server would support constants, a value that you could declare at the database level, that would allow the best query plan and still be simple to change. Sadly, I can't say that they're being introduced (not that I'm aware of). But with a little work, we can duplicate their functionality. For lack of a better term, I'll be referring to it as a Pseudo-Constant.

Using AdventureWorks, consider a scenario where the Shipping department need a special report for all "Overnight Shipping" orders. We'd typically choose one of three solutions for for implementing this query:

Using Variables

Using Literals

Using Stored Procedure Parameters

While a constant would rarely replace the need for parameters, it's worth mentioning their behavior for the sake of comparison. Through a feature called, "parameter sniffing", parameters give the query optimizer the best value for your first compiled execution but can often cause issues with subsequent calls that don't represent data of a similar cardinality. Among other places, parameter sniffing is discussed here and here.

Using Pseudo-Constants

Like a real constant, the pseudo-constant doesn't replace the need for parameters or variables. Instead, it's something that you might consider when you want the performance of a literal without the overhead maintenance of updating hundreds of procedures when a change is required.

Implementation:

Pseudo-Constants are not variables or parameters. Instead, they're simply views with one row, and enough columns to support your constants. With these simple rules, the SQL Engine completely ignores the value of the view but still builds an execution plan based on its value. The execution plan doesn't even show a join to the view!

To show its true power, we'll have to add some data to AdventureWorks database. I'm using the AdventureWorks2012 download from CodePlex and updating the SalesOrderHeader table to include a wider variety of data.

Data and Index Changes

[Sales].[SalesOrderHeader] currenly uses two of the five ship methods, which doesn't give us enough uniqueness of data. We're also missing an index on ShipMethodID so we'll make a few adjustments:

Pseudo-Constant creation

Our next step is to generate our Pseudo-Constants. As described above, we will create a table for each constant we require in our code. We'll also create a schema to keep things organized. This is not required but I find it improves readability. The data we're creating reflects the data in [Purchasing].[ShipMethod]

Testing Our Pseudo-Constants

Now that our view is in place, we can compare the overhead of a pseudo-constant with that of a variable and a literal. We'll start by turning on STATISTICS IO and then running the most selective query (OVERNIGHT J-FAST) against each implementation.

First Observations

There are two interesting things we see from STATISTICS IO output.
1. While the use of a standard JOIN or a variable show reads from the ShipMethod table, there are no observable reads from using the view.
2. Compared to literal and Pseudo-Constant, the logical reads against SalesOrderHeader are significantly higher with a standard JOIN or a variable.

Execution Plans

We can see here, that using a variable results in a clustered index scan. Since the value of @ShipMethodID is not known at compile time, the SQL engine has estimated that 104488.3 rows (one third of the total 31465 rows) will be returned. There are a lot of articles that describe this behavior including a great one by Kalen Delaney so I'm not going to cover it again here. I'll only mention that this is expected behavior when using variables in a query.

More interestingly, using Pseudo-Constants gives us the exact same execution plan as using a literal. The estimated and actual number of rows are a match because we know the value of ShipMethodID at compile-time.

Looking at the Index Seek operation, we even see that SQL Server is using the literal value 4 to determine the execution plan.

But Why Bother? Why not use Literals?

 So why not just use literal values? On the surface, it seems like Pseudo-Constants are a lot of work with no additional benefit, but we get some terrific advantages in medium-to-large projects:

1. Easier Dependency Tracking.
    When using variables, constants, or even JOINing to tables, we're never sure which lookup values are actually used. The removal of a row from the ShippingMethod table won't cause any compile errors in our code and will only present a problem when a query is actually executed. We may or may not even notice the problem. Using Pseudo-Constants gives us immediate visibility into dependencies:

2. Easier Code Refactoring.

When using a literal, updating an ID becomes a painful search-and-replace project. Changing every stored procedure that used "ShipMethodID = 4" to a new value like, "ShipMethodID = 6" requires a manual review of the code to look for these hard-coded values. In a large enough project, you'll never be sure you got them.
If you're using Pseudo-Constants, it's a simple process of querying the dependencies (as outlined aboce) or altering the underlying view to provide a new literal value.

3. The right data type every time.

From my own experience of seeing unexpected implicit data conversions, I know our literals and variables can sometimes use the wrong data type. This results in undetected performance hits when the SQL engine has to convert every row in the table to match the data type of your parameter. The Pseudo-Constant ensures you're only setting the data type in one place.

4. Instant Recompiles for data changes.

If the value of "OVERNIGHT J-FAST" changes, you're required to ALTER the view. This will result in all dependent objects to obtain a new plan for their next execution. While it's rarely valuable in this situation, it's extremely beneficial if you use Pseudo-Constants for date ranges.

Other Uses

1. Working in date ranges

Another exciting use of Pseudo-Constants is when working with date ranges. Pseudo-Constants can be used to supplement variables in returning a more selective dataset. I'll expand on this in a future post but imagine a query where the Psedo-Constant narrowed down your potential rows by 90% while the variable was used to get the exact range. This is far beneficial than a plan that returns all of your rows to be filtered at runtime.

 In closing

Disclaimer and a heartfelt thanks: Whenever possible, I will endeavor to give credit to people that provided a solution, idea, or inspiration for my own blog posts. These posts would not have possible without all the amazing people in the SQL Server community sharing their own solutions. While I'm not aware of anybody using this solution, I don't claim to be the first person to have thought of it. If there are any other sources for anything I cover, please contact me so that I may give proper attribution.

Pseudo-Constant Demo.sql

Note on file sizes: As a full of this sample run require 25GB of disk space, I've placed a simple restriction in the sample code. Prior to running the code without the restriction, readers should be familiar with TempDB file size settings and be aware of how much space they normally require.

Say Goodbye to large data scripts

Who could ever find those big data files with a forgotten name sitting in a forgotten folder on a forgotten server, protected by permissions that nobody has? We wanted to forget them but coming up with large, non-repeating data scripts can be a lot of work. Fortunately our friends at the U.S. Census Bureau love sharing data.

One of the Census Bureau's publications is a list of frequently occuring first names and surnames. Today, we'll download these data files and insert them into a table using nothing more than SQL Server Management Studio in SQLCMD mode.

The data we're using an aggregate of 1990 U.S. Census data. The full detail of the files, data format, and sampling methodology are available here. For our purposes, all we need to know is that it is a fixed-width data ASCII file and the "Name" column the first 15 characters of each line.

The files themselves have the following statistics:

The file itself looks like this:

PowerShell 2.0 Script

We'll start out by testing the smallest data file, dist.male.first. We need a way to download this through PowerShell and Boe Brox has a blog post that shows us how. In his article, we see that the Net.WebClient class provides our needed functionality. We'll run our first test by downloading a file and looking at the first 200 characters:

$URI="http://www.census.gov/genealogy/www/data/1990surnames/dist.male.first"
$web=New-Object Net.WebClient
$result=$web.DownloadString($URI)
$result.Substring(0,200)

In the results, we see that individual names are the only entries using letters. Additionally, there are no hyphenated names, apostrophes, or any other special characters in the name. This makes parsing very easy.

Having downloaded and viewed the file, we'll write a multi-line script in PowerShell, re-write it as a single-line script, then convert it to run in SQLCMD.

For multi-line, we will:

1. Remove any characters that are not alphabetical or CR/LF, leaving only names on each line.
2. Split each line into an array element; wrap the line in quotes/parenthesis. I.E. JAMES becomes ,('JAMES')
3. Generate an INSERT statement on every 100th line.
4. Test the results.

$URI="http://www.census.gov/genealogy/www/data/1990surnames/dist.male.first"
$web=New-Object Net.WebClient
$webResult=$web.DownloadString($URI)
# Using RegEx (Regular Expressions), eliminate anything that isn't Alpha or CRLF.
$webResult=$webResult -replace '[^a-z\r\n]',''
# Remove Blank Lines.
$webResult=$webResult -replace '\r\n[^a-z]',''
# Split each line into an array
$names=$webResult.Split("`n`r")
# Remove the empty line at the end of the file
$names=$names | Where-Object {$_.length -GT 1}
$lineCount=0
$names|ForEach-Object {
# Create a new batch every 100 lines
     if ($lineCount-- -le 0) {
        "GO`r`nINSERT #FirstName VALUES('$_')"
        $lineCount=100
     }
     else
     {
         ",('$_')"
     }
 } | Select-Object -First 10 # Test by selecting the first 10 lines

We should now have an output that looks like this:

Before we can put everything on one line, we want to take the additional step of removing unnecessary variables. This can be done through piping rather than storing results in a variable. We'll also shorten the variable names that we can't remove. Our code now looks like this:

$URI="http://www.census.gov/genealogy/www/data/1990surnames/dist.male.first"
$lc=0
((New-Object Net.WebClient).DownloadString($URI) -replace'[^a-z\r\n]',''-replace'\r\n[^a-z]','').Split("`n`r") |
    Where-Object {$_.length -GT1} |ForEach-Object {
     if ($lc---le0) {
        "GO`r`nINSERT #FirstName VALUES('$_')"
        $lc=100
     }
     else
     {
        ",('$_')"
     }
    } |Select-Object -First 10 # Test by selecting the first 10 lines

Finally, we remove all hope of readability by putting everything but the URI on one line like this:

$URI="http://www.census.gov/genealogy/www/data/1990surnames/dist.male.first"
$lc=0; ((New-Object Net.WebClient).DownloadString($URI) -replace '[^a-z\r\n]','' -replace '\r\n[^a-z]','').Split("`n`r") | Where-Object {$_.length -GT 1} |ForEach-Object { if ($lc -le 0) { "GO`r`nINSERT #FirstName VALUES('$_')"; $lc=100 } else { ",('$_')" } } | Select-Object -First 10

After testing the script one final time, we're ready to put it in SQLCMD.

Porting to SQLCMD

One More PowerShell SQLCMD caveat:

Adding quotes to your command can be a challenge. This is because SQLCMD and the Command Shell both attempt to strip quotes from strings. PowerShell often allows single quotes and double quotes interchangeably but it's not possible 100% of the time. With that, I (embarassingly) present the Quote variable:

:setvar Q """"""""

This variable, while not pretty, will be inserted into each of the sections that require double-quotes.

The Solution

The final query is shown below.

Reminder: As the full script results in a 25GB TempDB file, this script has been modified to return the first 20,000 rows. For demonstration purposes, a variable "SampleCount" limits the INSERT to 100 rows from each file (100 last * (100 first+100 first)). In addition to the 25GB disk requirement, running the full query on my system (a six-core desktop PC) took about 7 minutes. With that in mind, if you REALLY want to throttle your system to get all 487 million rows, simply comment out the second SETVAR command.

SET NOCOUNT ON
:out $(TEMP)\Names.sql
:setvar SampleCount ""
:setvar SampleCount "| Select-Object -First 100"
:setvar Q """"""""
:setvar PSCmd "PowerShell -InputFormat none -Command"
 
:setvar URI "http://www.census.gov/genealogy/www/data/1990surnames/dist.all.last"
!!$(PSCmd) "& { $lc = 0; ((New-Object Net.WebClient).DownloadString('$(URI)') -replace '[^a-z\r\n]','' -replace '\r\n[^a-z]','').Split($(Q)`n`r$(Q)) | Where-Object {$_.length -GT 1} | ForEach-Object { if ($lc-- -le 0) { $(Q)GO`r`nINSERT #LastNames  VALUES('$_')$(Q); $lc = 100 } else { $(Q),('$_')$(Q) } } $(SampleCount) }"
:setvar URI "http://www.census.gov/genealogy/www/data/1990surnames/dist.female.first"
!!$(PSCmd) "& { $lc = 0; ((New-Object Net.WebClient).DownloadString('$(URI)') -replace '[^a-z\r\n]','' -replace '\r\n[^a-z]','').Split($(Q)`n`r$(Q)) | Where-Object {$_.length -GT 1} | ForEach-Object { if ($lc-- -le 0) { $(Q)GO`r`nINSERT #FirstNames VALUES('$_')$(Q); $lc = 100 } else { $(Q),('$_')$(Q) } } $(SampleCount) }"
:setvar URI "http://www.census.gov/genealogy/www/data/1990surnames/dist.male.first"
!!$(PSCmd) "& { $lc = 0; ((New-Object Net.WebClient).DownloadString('$(URI)') -replace '[^a-z\r\n]','' -replace '\r\n[^a-z]','').Split($(Q)`n`r$(Q)) | Where-Object {$_.length -GT 1} | ForEach-Object { if ($lc-- -le 0) { $(Q)GO`r`nINSERT #FirstNames VALUES('$_')$(Q); $lc = 100 } else { $(Q),('$_')$(Q) } } $(SampleCount) }"
 
:out STDOUT
IF OBJECT_ID('tempdb..#FullNames') IS NOT NULL
    DROP TABLE #FullNames
IF OBJECT_ID('tempdb..#LastNames') IS NULL
    CREATE TABLE #LastNames(LastName VARCHAR(30))
IF OBJECT_ID('tempdb..#FirstNames') IS NULL
    CREATE TABLE #FirstNames(FirstName VARCHAR(30))
TRUNCATE TABLE #LastNames
TRUNCATE TABLE #FirstNames
GO
:r $(TEMP)\Names.sql
SELECT * INTO #FullNames FROM #LastNames CROSS JOIN #FirstNames
SELECT COUNT(*) AS NameCount FROM #FullNames

For readability (seriously), I've added extra spaces between lines. If you want the promised "20 lines of code" from the title, you can actually get it down to 17 by removing extra spacing and concatenating all of your T-SQL (putting a semicolon between each command). You can get it to 15 lines by removing the SampleCount variables.

Extending the Solution

We took a lot of steps to reduce this to the bare-minimum data for the demo but the best data representation would actually have repeating names. If America has 314 million people, our table should have 104,810 people named James Smith (and 2.22 people named Jared Ko). This is all available from the other columns in these tables.

We could also add demographic information, income ranges, give them all a place to live, and if we're still not tired, start building our international database.

Additional Reading

• PowerShell - Working With Regular Expressions (regex)
• (Hey Scripting Guy) Use Windows PowerShell to Replace Characters in a Text File
• Using PowerShell to Query Web Site Information
• Piping and the pipeline

GenerateNames.sql

Goodbye Command Shell. Hello PowerShell.

It seems like the relationship between SQL Server and PowerShell is getting a lot of attention lately. Wayne Sheffield just ran a series titled, "A month of PowerShell" which covers just about everything you could want to know about SQL SMO and PowerShell. As I've started using PowerShell in early 2011, there's not much I can add to what Wayne's doing. So instead of using PowerShell to connect to SQL Server, we're going to use SQLCMD mode to talk to PowerShell.

This is new way of using SQLCMD that I'm really excited about. It's not part of any service pack but something that's been available to us for a very long time. It seems that we just failed to notice. Though PowerShell, we can start executing CmdLets, small pieces of code, and combine pieces of SQL Server with PowerShell to make everything a little bit easier.

Running PowerShell from SQLCMD

First, an undocumented parameter

An important thing to note (and required for PowerShell 2.0 users): When running PowerShell through SQLCMD, you should always include the following parameter:

 -InputFormat none

The problem is described here and, while PowerShell 3.0 behaves fine without this switch, I personally leave it in my scripts for backwards compatibility.

Want BCP? Remember where your server is

As I present these scripts, it's with the assumption that your client PC and your server are not the same machine. This means that I won't use BCP or other commands that assume your data is on the same computer as your server.

The script-signing barrier

Upon installation, PowerShell's default security level prohibits the execution of unsigned scripts. This is a very important feature and one that can easily be configured to an individual's needs. While changing this setting would make things easier, I like to find solutions that work "out of the box", without changes to system settings or additional software. Its with this goal in mind that I'm providing solutions that will execute without changing the default PowerShell security settings. There are easier and cleaner ways but (as far as I know) this is the only way to do it without extra steps.

Let's form a nice, long line...

The last thing to remember is that we're performing each PowerShell call in a single line with a semicolon ( ; ) between commands.While there are some tricks to improve readability, it still won't match up to the clean style you get from other code.

Hello PowerShell World

What script would be complete without the obligatory "Hello World"? All you have to do is make sure PowerShell is installed, turn on SQLCMD mode, and execute the following line:

!! PowerShell -InputFormat none -Command "& { Write-Output 'Hello PowerShell World!' }"

If everything went well, you'll see an output similar to this:

Let's Make a Numbers Table

Adam Mechanic has a post titled, You REQUIRE a numbers table! Adam took over 15 lines to write the SELECT part (probably because he had a choice) but we're going to do it in one line (because we don't have a choice). It's also going to be slower and less-legible than Adam's, but... well... We're doing it in PowerShell! That's got to count for something!

-- Execute CREATE TABLE from within our script
:OUT $(TEMP)\Numbers.sql
PRINT '
SET NOCOUNT ON
USE TempDB
GO
IF OBJECT_ID(''Numbers'') IS NULL CREATE TABLE Numbers (Number INT)
TRUNCATE TABLE TempDB..Numbers
GO
'
-- If you forget the GO statement, the lower code executes first.
GO
!! PowerShell -InputFormat none -Command "& { (1..1000) | ForEach-Object {Write-Output ('INSERT Numbers VALUES (' + $_ + ')' )} }"
-- Redirect output to the message pane
:OUT STDOUT
-- Execute our newly-created script.
:r $(TEMP)\Numbers.sql
-- Check for our numbers table
SELECT * FROM tempdb ..Numbers

After executing the above code, you should see results that look similar to this:

Note that the results won't show up in grid mode (even if you've chosen "Results to Grid"), but will be present in the "Messages" tab instead. This is a result of redirecting output to STDOUT.

SQLCMD variables for script block reuse

Finally, let's make it even easier to run our code. Nobody wants to risk a typo or waste screen real-estate when these PowerShell scripts start getting really long.

!! PowerShell -InputFormat none -Command "& { Write-Output 'Out with the old.' }"

:setvar PSCmd "PowerShell -InputFormat none -Command"

!!$(PSCmd) "& { Write-Output 'In with the new!' }"
!!$(PSCmd) "& { Write-Output 'This is a little easier to read.' }"

Next up: Say Hello to 450 million of your closest friends.

In the next post, I'll provide you with a 20-line script to generate a table of 450 million unique names. Following that, I'll take a break from SQLCMD and PowerShell to introduce something new (or new to me) on the SQL Server performance side.

The steps outlined in this article deal with executing dynamically-generated files. Though we are creating and running our own files in the same script, the results are less-predictable as complexity increases. Whenever trying sample code (from anywhere), you should execute in an environment that can tolerate accidental loss.

Not SQLCMD I Already Tried It...

If you're like me, you've probably spent the last several years in and out of SQL Server Management Studio's SQLCMD mode. It's got some great functionality but activating it came with the cost of disabling IntelliSense. Personally, I've always ended up turning it off and forgetting it for several months... Until Now...

Over the next several posts, I'm going to cover all the issues that made you give up on SQLCMD mode in the past. My goal isn't to make you keep that button active in SSMS, but to make you consider it as the productivity enhancer you'll never forget again.

This post begins with workaround for minor annoyances like the inability to program variables. The second post will quickly move out of command shell basics and provide background for the third post, where the fun really begins. In the third post I'll show you how to write 20 lines of code to create a sample "people" table with 450 million unique names.

Oh yeah... I don't have a solution for using IntelliSense with SQLCMD mode but it'll still be worth it....

But I Can't Programmatically Set My Variables

SQLCMD mode allows you to set variables based on literal values. Unfortunately you can't set variables based on the output of SQL Server. It's also not possible through concatenation of other SQLCMD variables or with environment variables.

(This is not supported)

:SETVAR FileName (SELECT @@Servername + '.txt')

:SETVAR NewVar $(OldVar1)$(OldVar2)

(This is not supported)

While we can't use the syntax above, we can still get the desired results by generating the script in a second file.

Programmatically Generating a "Variables File"

The following script generates a file called "GetServerName.sql" in the system temp folder. The file contents, a SETVAR command, will then be read from the same script. 

After executing "GetServerName", we'll use our new variable $(Filepath) to create a test file of system users (server_principals).

Just for fun, we'll also open both files in to review them Notepad at the end. Remember to close Notepad because SQLCMD is patiently waiting and won't continue until you do.

:OUT $(TEMP)\GetServerName.sql
PRINT ':SETVAR FilePath $(TEMP)\' + @@SERVERNAME + '.txt'
GO
:OUT stdout
:r $(TEMP)\GetServerName.sql
GO
:OUT $(FilePath)
SELECT name, create_date 
FROM master.sys.server_principals
GO
:OUT stdout
!!notepad $(TEMP)\GetServerName.sql
!!notepad $(FilePath)

Some important items to note:

• Observe the file path when notepad opens the first file (GetServerName.sql). Notice that the system parameter, $(TEMP), has already resolved itself to the full path of the temp directory.
• Be aware of the backslash character ( \ ) preceding a variable as it behaves like an escape character, negating the $ of the next variable.

There's no conditional (If/Then) logic in SQLCMD

True again! And how do we fix that? We're going to solve this one with another dynamically-generated file.

Suppose we wanted BULK IMPORT a local file from a drop folder, run BCP, or process a set of other SQLCMD functions. If our target files didn't exist, we'd normally have no way to exit the script. However, we can use DOS commands to perform similar actions to those in the previous example. We do this by generating a file that contains one of two scripts (based on a condition being met). We first create a "Fail/Exit" file. As we execute, we replace the file when we succeed.

-- SQLCMD Error Handling
:setvar ErrorCheckFile "ErrorCheckFile.sql"
 
-- Set DOS commands that will display in the output window and run SQLCMD EXIT.
:setvar ErrorStatusCommand "(ECHO !!ECHO ValidationFailure. Terminating Script. && ECHO :Exit)"
 
-- The following line creates the file. Use this line for each situation that might require us to stop.
!! $(ErrorStatusCommand) > $(TEMP)$(ErrorCheckFile)
 
-- See if a file exists. If so, replace our EXIT command with a blank file.
!! If EXIST $(TEMP)\*.* @ECHO. > $(TEMP)$(ErrorCheckFile)
 
-- Now read/execute the result
:r $(TEMP)$(ErrorCheckFile)
!! ECHO Found files in the Temp folder (this is normal).
!! ECHO.
!! ECHO Checking Next File.
 
-- Reset the file back to Exit
!! $(ErrorStatusCommand) > $(TEMP)$(ErrorCheckFile)
-- Try again with a file that shouldn't exist
!! If EXIST $(TEMP)\ThisFileShouldNotBeHere.txt @ECHO. > $(TEMP)$(ErrorCheckFile)
 
-- Now read/execute the result
:r $(TEMP)$(ErrorCheckFile)
!! ECHO You should not see this.
PRINT 'You should not see this either'

If our script ran correctly, the output window will contain the following text:

Found files in the Temp folder (this is normal).

Checking Next File.
ValidationFailure. Terminating Script.


Okay... Fancy DOS tricks... Is that it?

Nope. This is where we start to have fun. We'll take it up a level in the next post but we needed to do the basics first. For now, I'll leave you with a way to perform loops.

This script executes itself in a loop. In order for it to work, you need to save it in the temp folder as "Loop.sql"  (the quickest way to do that is to put %TEMP%\Loop.sql in the Save-As box). Alternatively, you can update the script to reflect the file path of your choosing.

SET NOCOUNT ON

IF OBJECT_ID('tempdb..#state') IS NULL

BEGIN

    CREATE TABLE #state(TheStart DATETIME2)

    INSERT #state VALUES(DATEADD(S, 1, SYSDATETIME()))

END

GO

PRINT 'Beginning Loop1'

GO

DECLARE @TimeRemaining INT

SELECT TOP 1 @TimeRemaining = DATEDIFF(MS, SYSDATETIME(), TheStart) FROM #state

PRINT CAST(@TimeRemaining AS VARCHAR) + ' milliseconds to go...'

GO

:out $(TEMP)\loop2.sql

IF SYSDATETIME() <=(SELECT TOP 1 TheStart FROM #state)

BEGIN

    PRINT 'PRINT ''Hello from loop2'''

    PRINT ':r $(TEMP)\loop.sql'

END

ELSE

BEGIN

    PRINT 'PRINT ''Last visit to Loop2!'''

    PRINT 'DROP TABLE #state'

END

GO

:out STDOUT

WAITFOR DELAY '0:00:00.1'

GO

PRINT 'Running loop-checker...'

GO

:r $(TEMP)\loop2.sql

 A final note about debugging

From my experience with SQLCMD Mode, the most-common causes of unexpected results were attributed to a missing GO statement or not inserting white space between lines.

• SQLCMD loves white space. If your command isn't working correctly, try adding a space above it... and below it...
• SQLCMD also loves to parse everything and it won't want for the SQL Engine to return a response. If you need SQLCMD to work with an output from SQL Server, throw in a GO statement.
• Remember not to put a backslash in front of a variable name. This does NOT work: $(TEMP)\$(FileName)
• Add more vertical space. Add more GO statements.