Take this simple example
SELECT GETDATE()
GO
SELECT 1/asasasas
GO
You can probably guess that the second statement is not valid, when you have a lot of code it is more difficult to spot these things.
Execeute the code above and you will get this
(1 row(s) affected)
Server: Msg 207, Level 16, State 1, Line 1
Invalid column name 'asasasas'.
SQL server has the SET NOEXEC statement. From BOL:
When SET NOEXEC is ON, Microsoft® SQL Server™ compiles each batch of
Transact-SQL statements but does not execute them. When SET NOEXEC is OFF, all
batches are executed after compilation.
The execution of statements in
SQL Server consists of two phases: compilation and execution. This setting is
useful for having SQL Server validate the syntax and object names in
Transact-SQL code when executing. It is also useful for debugging statements
that would usually be part of a larger batch of statements.
The setting
of SET NOEXEC is set at execute or run time and not at parse time.
So execute the code below
SET NOEXEC ON
GO
SELECT GETDATE()
GO
SELECT 1/asasasas
GO
SET NOEXEC OFF
GO
As you can see the output is the following:
Server: Msg 207, Level 16, State 1, Line 1
Invalid column name 'asasasas'.
You never see the getdate. Parsing that code will not throw an error and because of deferred name resolution you can fat-finger table names and it will parse without a problem.