Hi Magnus, ( cool name ... wish I had a name like that :-) )

Yes, your observation is surely correct, which is why I mentioned it as a possible issue. My thought was if he is performing several "unrelated" operations that do not directly depend on each other he might possibly use this technique to keep his memory usage to a minimum. I agree with Kevin that Daniel's suggestion is the best, to analyze/optimize the methodology used.

Bill

>Hi Bill.
>
>If you use a GO in the sp all local variables are cleared.
>It be a problem if you declare vars that you need further on in the sp.
>
>From BOL:
>"The scope of a local variable is the batch, stored procedure, or statement block in which it is declared. For more information about using local variables in statement blocks, see Using BEGIN...END."
>
>>Hi Kevin,
>>
>>Not sure on this but aren't variables scoped to the batch? If so and the batch is completed with a GO statement, wouldn't the variables be released? In that case, as long as his processes could be segregated he could "release" his variables this way. Yes-No?
>>
>>Bill
>>
>>>Fabio,
>>>
>>>I honestly do not have an answer as to "why" - whether it was an architectural issue, or something completely different.
>>>
>>>All I can tell you is that you cannot drop a table variable when it is no longer necessary. It simply goes out of scope when the proc completes.
>>>
>>>It seems you can do a DELETE FROM @tTableVar at any time, though I have no idea if that would have the desired effect on resource usage.
>>>
>>> Someone must tell me why not there is RELEASE @table.
>>>If I had implemented DECLARE @table TABLE,
>>>after a second I would have implemented RELEASE @Table.
>>>Simple very simple.
>>>
>>>I think it's simple/easy to say that... ;)
>>>
>>>Kevin