Question

We have an SSIS package that ran in production on a SQL 2008 box with a 2005 compatibility setting. The package contains a SQL Task and it appears as though the SQL at the end of the script did not run.

The person who worked on that package noted before leaving the company that the package needed “GOs” between the individual SQL commands to correct the issue. however, when testing in development on SQL Server 2008 with 2008 compatibility, the package worked fine.

From what I know, GO‘s place commands in batches, where commands are sent to the database provider in a batch, for efficiency’s sake. I am thinking that the only way that GO should effect the outcome is if there was an error in that script somewhere above it. I can imagine GO in that case, and only that case, effecting the outcome. However, we have seen no evidence of any errors logged.

Can someone suggest to me whether or not GO is even likely related to the problem? Assuming no error was encountered, my understanding of the “GO” command suggests that it use or lack of use is most likely unrelated to the problem.

Answer 1

The GO keyword is, as you say, a batch separator that is used by the SQL Server management tools. It’s important to note, though, that the keyword itself is parsed by the client, not the server.

Depending on the version of SQL Server in question, some things do need to be placed into distinct batches, such as creating and using a database. There are also some operations that must take place at the beginning of a batch (like the use statement), so using these keywords means that you’ll have to break the script up into batches.

A couple of things to keep in mind about breaking a script up into multiple batches:

• When an error is encountered within a batch, execution of that batch stops. However, if your script has multiple batches, an error in one batch will only stop that batch from executing; subsequent batches will still execute
• Variables declared within a batch are available to that batch only; they cannot be used in other batches

If the script is performing nothing but CRUD operations, then there’s no need to break it up into multiple batches unless any of the above behavioral differences is desired.