Does SQL Server have anything like VB's On Error GoTo?

To those familiar with Visual Basic, VB provides the option to use the ON ERROR GOTO ... clause to catch practically any error and handle it in one's program.Does SQL Server 2000 have the analogous clause that will jump to a certain part of code in a stored procedure to handle errors?Solution: Errors must be checked after every SQL statement of interest.In short: No! SQL Server does not have anything like Visual Basic's "On Error GoTo" construct. It acts as if there was always an "On Error Resume Next" statement in effect.For effective error handling in a SQL Server stored procedure you must test the value of @@ERROR after EVERY SQL statement that might produce an error. Yes, that's a lot of testing. A well written stored procedure will often be 1/2 or more error handling code.There's another important consideration in designing error handling: @@ERROR is reset after each and every SQL statement, @@ROWCOUNT is also similarly reset. Therefore, you must capture both of these immediatly after each SQL statement that might produce an error. I start by declaring two variables to hold the values of @@ERROR and @@ROWCOUNT while the error handling code is working with them. They're declared at the top of every stored procedure and I've added them to my stored procedure template.
DECLARE @myERROR int -- Local @@ERROR , @myRowCount int -- Local @@ROWCOUNT

Next let's say that we had a simple INSERT statement

INSERT INTO Authors (au_id, au_fname, au_lname, contract) VALUES ('1234' , 'Arun, 'paramesh' , 1 )

Immediately after that statement, you should have the following statement:

SELECT @myERROR = @@ERROR , @myRowCOUNT = @@ROWCOUNT

These two assignements must be in the same statement. If you were to split them into two statements, for instance:

SET @myERROR = @@ERRORSET @myRowCOUNT = @@ROWCOUNTthen @myRowCOUNT

would always be zero. That's because it's reflecting the number of rows effected by the

SET @myERROR = @@ERROR statement that preceeds it.

Thanks,

Arun.

ASP.NET Web Forms

The ASP.NET Web Forms page framework is a scalable common language runtime programming model that can be used on the server to dynamically generate Web pages.
Intended as a logical evolution of ASP (ASP.NET provides syntax compatibility with existing pages), the ASP.NET Web Forms framework has been specifically designed to address a number of key deficiencies in the previous model. In particular, it provides:

The ability to create and use reusable UI controls that can encapsulate common functionality and thus reduce the amount of code that a page developer has to write.

The ability for developers to cleanly structure their page logic in an orderly fashion (not "spaghetti code").

The ability for development tools to provide strong WYSIWYG design support for pages (existing ASP code is opaque to tools).

ASP.NET Web Forms pages are text files with an .aspx file name extension. They can be deployed throughout an IIS virtual root directory tree. When a browser client requests .aspx resources, the ASP.NET runtime parses and compiles the target file into a .NET Framework class. This class can then be used to dynamically process incoming requests. (Note that the .aspx file is compiled only the first time it is accessed; the compiled type instance is then reused across multiple requests).
An ASP.NET page can be created simply by taking an existing HTML file and changing its file name extension to .aspx (no modification of code is required). For example, the following sample demonstrates a simple HTML page that collects a user's name and category preference and then performs a form postback to the originating page when a button is clicked:

ASP.NET provides syntax compatibility with existing ASP pages. This includes support for <% %> code render blocks that can be intermixed with HTML content within an .aspx file. These code blocks execute in a top-down manner at page render time.

ASP.NET page developers can utilize code blocks to dynamically modify HTML output much as they can today with ASP. For example, the following sample demonstrates how code blocks can be used to interpret results posted back from a client.

While code blocks provide a powerful way to custom manipulate the text output returned from an ASP.NET page, they do not provide a clean HTML programming model. As the sample above illustrates, developers using only code blocks must custom manage page state between round trips and custom interpret posted values.