>I have a debug problem. When running this code (just a small snippet) with the print statement, I have no problem, but if I remove the print statement or move it above the select, I end up in a loop. Does the print effect the @@Rowcount some how?
>
>

>	SELECT @RoomDate = RoomDate, @DeptId = DeptId, @DeptDesc = DeptDesc, @RoomId = RoomId, @RoomName = RoomName,
                      @SpaceStart = SpaceStart, @SpaceEnd = SpaceEnd, @SpaceMinutes = SpaceMinutes 
>	FROM @OUTPUT 
>	WHERE ID = @TempId
>	
>        print 'Test'
>
>	WHILE(@@ROWCOUNT > 0)
>	BEGIN
>

>
>Thanks for any thoughts.

SELECT * FROM AnyTable
SELECT @@ROWCOUNT  --- Some value here
print 'test'
SELECT @@ROWCOUNT --- ZERO

Here what BOL said:

Transact-SQL statements can set the value in @@ROWCOUNT in the following ways:

Set @@ROWCOUNT to the number of rows affected or read. Rows may or may not be sent to the client.


Preserve @@ROWCOUNT from the previous statement execution.


Reset @@ROWCOUNT to 0 but do not return the value to the client.


Statements that make a simple assignment always set the @@ROWCOUNT value to 1. No rows are sent to the client. Examples of these statements are: SET 
@local_variable, RETURN, READTEXT, and select without query statements such as SELECT GETDATE() or SELECT 'Generic Text'.

Statements that make an assignment in a query or use RETURN in a query set the @@ROWCOUNT value to the number of rows affected or read by the query, for 
example: SELECT @local_variable = c1 FROM t1.

Data manipulation language (DML) statements set the @@ROWCOUNT value to the number of rows affected by the query and return that value to the client. The DML 
statements may not send any rows to the client.

DECLARE CURSOR and FETCH set the @@ROWCOUNT value to 1.

EXECUTE statements preserve the previous @@ROWCOUNT.

Statements such as USE, SET <option>, DEALLOCATE CURSOR, CLOSE CURSOR, BEGIN TRANSACTION or COMMIT TRANSACTION 
reset the ROWCOUNT value to 0.

So maybe print is one of these commands.