Rules associated with batches

There are rules governing 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 that 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.