Exception report in the SQL Profiler

Hello,
I keep getting an Event Class 'Exception' in the SQL Profiler.
The text data is 'Error: 208, Severity: 16, State: 0'
However, neither ObjectID or the ObjectName colums are populated.
Error 208 states that object which does not exist is referenced.
However, I can't seem to pinpoint what it's actually complaining about.
The application that calls the sproc where this occurs reports no errors
and the sprocs do execute fine.
How can I troubleshoot this problem?
ThanksFrank Rizzo wrote:
> Hello,
> I keep getting an Event Class 'Exception' in the SQL Profiler.
> The text data is 'Error: 208, Severity: 16, State: 0'
> However, neither ObjectID or the ObjectName colums are populated.
> Error 208 states that object which does not exist is referenced.
> However, I can't seem to pinpoint what it's actually complaining
> about.
> The application that calls the sproc where this occurs reports no
> errors and the sprocs do execute fine.
> How can I troubleshoot this problem?
> Thanks
Many 208 errors are generated because of temp table use and do not
indicate there is actually a problem.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||David Gugick wrote:

> Frank Rizzo wrote:
>
>
> Many 208 errors are generated because of temp table use and do not
> indicate there is actually a problem.
Ok, but how can I be sure? Also, exactly what about the temp table
actually generates this exception.|||Frank Rizzo wrote:
> Ok, but how can I be sure? Also, exactly what about the temp table
> actually generates this exception.
When a stored procedure is called and there is no plan in cache, SQL
Server generates a new plan. At compile time, the temp table (assuming
it is created in the proc) does not exist and SQL Server kicks out the
208 error (sometimes multiple ones). That is, an object is accessed, but
does not exist, even though it's really fine.
Once the plan is in cache, subsequent executions don't cause the error
unless you are really dealing with an object that is missing.
If this occurrs from a stored procedure, you can examine the
SP:StmtStarting event just prior to the 208 Exception. That's the
statement that triggered the problem. If you also see a 208 Exception
before the SP:CacheInsert and SP:Starting events, that's because when
the procedure was compiled, the object was missing (that's where you'd
see the errors for temp tables as well on the initial execution).
From outside a stored procedure, have a look at the SQL:StmtStarting or
RPC:Starting event for the trigger text.
There's no easy way to determine the bad from the acceptable 208 errors
other than examining the trace in more detail and seeing what statements
triggered the problem.
David Gugick
Quest Software
www.imceda.com
www.quest.com