There are rules to govern which Transact-SQL statements can be combined into a single batch. These batch rules are as follows:
Before referencing objects in a database, issue a use statement for that database. For example:
use master go select count(*) from sysdatabases go
You cannot combine the following database commands with other statements in a batch:
create procedure
create rule
create default
create trigger
You can combine the following database commands with other Transact-SQL statements in a batch:
create database (except you cannot create a database and create or access objects in the new database in a single batch)
create table
create index
create view
You cannot bind rules and defaults to columns and use them in the same batch. sp_bindrule and sp_bindefault cannot be in the same batch as insert statements that invoke the rule or default.
You cannot drop an object and then reference or re-create it in the same batch.
If a table already exists, you cannot re-create it in a batch, even if you include a test in the batch for the table’s existence.
Adaptive Server compiles a batch before executing it. During compilation, Adaptive Server makes no permission checks on objects, such as tables and views, that are referenced by the batch. Permission checks occur when Adaptive Server executes the batch. An exception to this is when Adaptive Server accesses a database other than the current one. In this case, Adaptive Server displays an error message at compilation time without executing any statements in the batch.
Assume that your batch contains these statements:
select * from taba select * from tabb select * from tabc select * from tabd
If you have the necessary permissions for all statements except the third one (select * from tabc), Adaptive Server returns an error message for that statement and returns results for all the others.
