vijayanandgawle

The ASP .NET ScriptManager manages ASP.NET Ajax script libraries and script files, partial-page rendering, and client proxy class generation for Web and application services. Here are some tips for the ScriptManager that I have found useful. Please note that many of these topics apply to ASP .NET 4.0. Access ScriptManager From Child You can only have one instance of the ScriptManager per page, so a common practice for a web form application that uses Master Pages is to put that reference in the master page. To access this instance from the child page, you must call the GetCurrent static method and pass in a reference to the page. ScriptManager sm = ScriptManager.GetCurrent(this); Access ScriptManager From UserControl From a user control, you do the same thing, but this time the page reference comes from the Control.Page property. ScriptManager sm = ScriptManager.GetCurrent(this.Page); Register Async PostBack Control To register a control as a trigger for asynchronous postbacks from

When you work with master pages and content pages, both can use the same events (such as Page_Load).Be sure you know which events come before others. You are bringing two classes together to create a singlepage class, and a specific order is required. When an end user requests a content page in the browser, the event ordering is as follows: Master page child controls initialization: All server controls contained within the master page are first initialized. Content page child controls initialization: All server controls contained in the content page are initialized. Master page initialization: The master page itself is initialized. Content page initialization: The content page is initialized. Content page load: The content page is loaded (this is the Page_Load event followed by the Page_LoadComplete event). Master page load: The master page is loaded (this is also the Page_Load event). Master page child controls load: The server controls on the master page are loaded onto the pa

http://dotnetguts.blogspot.com/2007/08/faq-on-view-in-sql-server.html

You cannot call server-side code ‘directly’ from client-side code. That is because by design, the server side code executes at server side and client side code at the client. However there are some workarounds. To call serverside code from javascript, you will need to use AJAX, and the easiest way out, is to use the ASP.NET AJAX Extensions. One option while using Microsoft ASP.NET AJAX is to call ASP.NET Web services (.asmx files) from the browser by using client script. The script can call a webservice containing server-based methods (Web methods) and invoke these methods without a postback and without refreshing the whole page. However this approach could be overkill sometimes, to perform the simplest of tasks. Moreover the logic needs to be kept in a separate .asmx file. We need something that is more ‘integrated’ with our solution. The option we are going to use in this article involves PageMethods. A PageMethod is basically a public static method that is exposed in the code-behi

Syntax: BEGIN TRY { sql_statement | statement_block } END TRY BEGIN CATCH { sql_statement | statement_block } END CATCH The TRY or CATCH block can contain a single T-SQL statement or a series of statements. The CATCH block must follow immediately after the TRY block. The TRY/CATCH block cannot span more than a single batch. In addition, TRY/CATCH block cannot span an IF/ELSE statement. Example of TRY…CATCH: BEGIN TRY DECLARE @X INT ---- Divide by zero to generate Error SET @X = 1 / 0 PRINT 'Command after error in TRY block' END TRY BEGIN CATCH PRINT 'Error Detected' END CATCH PRINT 'Command after TRY/CATCH blocks' Above code will return following result: Error Detected Command after TRY/CATCH blocks If all the statements within the TRY block are executed successfully, then processing does not enter the CATCH block, but instead skips over the CATCH block and executes the first statement following the END CATCH statement. Removing SET statement in above cod

Q1: Why were table variables introduced when temporary tables were already available? A1: Table variables have the following advantages over temporary tables: As mentioned in the SQL Server Books Online "Tables" article, table variables, such as local variables, have a well defined scope at the end of which they are automatically cleared. Table variables result in fewer recompilations of a stored procedure as compared to temporary tables. Transactions that involve table variables last only for the duration of an update on the table variable. Therefore, table variables require less locking and logging resources. Because table variables have limited scope and are not part of the persistent database, transaction rollbacks do not affect them. Q2: What does it mean by saying that table variables result in fewer recompilations of a stored procedure than when temporary tables are used? A2: The following article discusses some reasons when store