|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
The value of @@Error after Select statementHi,
I have been asked to check the value of @@Error after some of my Select statements but I think that I don't need to. Could you please tell me in what conditions we have none zero value in @@Error after a SELECT statement? If SELECT doesn't return any record, it doesn't return any error (@@Error will be 0). Thank you, Rosie >> Could you please tell me in what conditions we have none zero value in Not sure if I fully understood what you are asking, but if there is no error >> @@Error after a SELECT statement? in the last executed Transact-SQL statement, @@ERROR will be zero. I don't think you can enumerate all the "conditions" which results in a non-zero value for @@ERROR. -- Anith For SELECT, it's probably a pretty narrow set of circumstances (lost
connection to server, table name or column names changed, inadequate permissions, etc.). BOL has an exhaustive list of error codes. Show quote "Rosie" <Ro***@discussions.microsoft.com> wrote in message news:9253E784-7C80-4D4B-9019-D096E6C2E752@microsoft.com... > Hi, > I have been asked to check the value of @@Error after some of my Select > statements but I think that I don't need to. Could you please tell me in > what > conditions we have none zero value in @@Error after a SELECT statement? > > If SELECT doesn't return any record, it doesn't return any error (@@Error > will be 0). > > Thank you, > Rosie > In sysmessages system table, is there any way that I can list all the errors
that are created by a Select statement? or I have to scan the table? I'm looking for the temporary conditions that last very short period of time(one second or less) and raise error for a simple query with simple joins (with no calculations) . Thanks, Rosie Show quote "Michael C#" wrote: > For SELECT, it's probably a pretty narrow set of circumstances (lost > connection to server, table name or column names changed, inadequate > permissions, etc.). BOL has an exhaustive list of error codes. > > "Rosie" <Ro***@discussions.microsoft.com> wrote in message > news:9253E784-7C80-4D4B-9019-D096E6C2E752@microsoft.com... > > Hi, > > I have been asked to check the value of @@Error after some of my Select > > statements but I think that I don't need to. Could you please tell me in > > what > > conditions we have none zero value in @@Error after a SELECT statement? > > > > If SELECT doesn't return any record, it doesn't return any error (@@Error > > will be 0). > > > > Thank you, > > Rosie > > > > > I would think that most errors that would occur because of a simple SELECT
statement would be mostly syntactical in nature or would be caused by other underlying issues (such as connectivity issues, renamed or deleted tables/columns), etc. Checking the value of @@error after a SELECT statement might help you narrow down the problem, but it probably will not be resolvable via trapping the error in your front end; other than letting the developer or end user know that the problem exists. You'll need to fix the underlying problem... You can select the error message that occurs using something like this: SELECT * FROM master.dbo.sysmessages WHERE error = @@error After a statement. I think someone already mentioned that some statements will terminate a batch so this isn't full-proof. Show quote "Rosie" <Ro***@discussions.microsoft.com> wrote in message news:E80C8F31-975A-4789-9AA0-F22ED21E6C37@microsoft.com... > > In sysmessages system table, is there any way that I can list all the > errors > that are created by a Select statement? or I have to scan the table? > > I'm looking for the temporary conditions that last very short period of > time(one second or less) and raise error for a simple query with simple > joins (with no calculations) . > > Thanks, > Rosie > > "Michael C#" wrote: > >> For SELECT, it's probably a pretty narrow set of circumstances (lost >> connection to server, table name or column names changed, inadequate >> permissions, etc.). BOL has an exhaustive list of error codes. >> >> "Rosie" <Ro***@discussions.microsoft.com> wrote in message >> news:9253E784-7C80-4D4B-9019-D096E6C2E752@microsoft.com... >> > Hi, >> > I have been asked to check the value of @@Error after some of my Select >> > statements but I think that I don't need to. Could you please tell me >> > in >> > what >> > conditions we have none zero value in @@Error after a SELECT statement? >> > >> > If SELECT doesn't return any record, it doesn't return any error >> > (@@Error >> > will be 0). >> > >> > Thank you, >> > Rosie >> > >> >> >> Thanks!
Show quote "Michael C#" wrote: > I would think that most errors that would occur because of a simple SELECT > statement would be mostly syntactical in nature or would be caused by other > underlying issues (such as connectivity issues, renamed or deleted > tables/columns), etc. > > Checking the value of @@error after a SELECT statement might help you narrow > down the problem, but it probably will not be resolvable via trapping the > error in your front end; other than letting the developer or end user know > that the problem exists. You'll need to fix the underlying problem... > > You can select the error message that occurs using something like this: > > SELECT * FROM master.dbo.sysmessages WHERE error = @@error > > After a statement. I think someone already mentioned that some statements > will terminate a batch so this isn't full-proof. > > "Rosie" <Ro***@discussions.microsoft.com> wrote in message > news:E80C8F31-975A-4789-9AA0-F22ED21E6C37@microsoft.com... > > > > In sysmessages system table, is there any way that I can list all the > > errors > > that are created by a Select statement? or I have to scan the table? > > > > I'm looking for the temporary conditions that last very short period of > > time(one second or less) and raise error for a simple query with simple > > joins (with no calculations) . > > > > Thanks, > > Rosie > > > > "Michael C#" wrote: > > > >> For SELECT, it's probably a pretty narrow set of circumstances (lost > >> connection to server, table name or column names changed, inadequate > >> permissions, etc.). BOL has an exhaustive list of error codes. > >> > >> "Rosie" <Ro***@discussions.microsoft.com> wrote in message > >> news:9253E784-7C80-4D4B-9019-D096E6C2E752@microsoft.com... > >> > Hi, > >> > I have been asked to check the value of @@Error after some of my Select > >> > statements but I think that I don't need to. Could you please tell me > >> > in > >> > what > >> > conditions we have none zero value in @@Error after a SELECT statement? > >> > > >> > If SELECT doesn't return any record, it doesn't return any error > >> > (@@Error > >> > will be 0). > >> > > >> > Thank you, > >> > Rosie > >> > > >> > >> > >> > > > If the SELECT fails for any reason, @@error would produce a non-zero value,
e.g., select 1/0 select @@error select log(0) select @@error Note that some errors terminate the batch, so you won't have a chance to trap those with T-SQL (e.g., conversion error, deadlock): select 'a'+1 select @@error Show quote "Rosie" <Ro***@discussions.microsoft.com> wrote in message news:9253E784-7C80-4D4B-9019-D096E6C2E752@microsoft.com... > Hi, > I have been asked to check the value of @@Error after some of my Select > statements but I think that I don't need to. Could you please tell me in what > conditions we have none zero value in @@Error after a SELECT statement? > > If SELECT doesn't return any record, it doesn't return any error (@@Error > will be 0). > > Thank you, > Rosie >  
Other interesting topics
|
|||||||||||||||||||||||
