SQL Queries

1. To get version of SQL server and operating system?

• SELECT SERVERPROPERTY (‘productversion’), SERVERPROPERTY (‘productlevel’), SERVERPROPERTY (‘edition’)

2. How to find tables without Indexes?

• SELECT SCHEMA_NAME(schema_id) AS schema_name,name AS table_name FROM sys.tables WHERE OBJECTPROPERTY(OBJECT_ID,‘IsIndexed’) = 0ORDER BY schema_name, table_name;

3. Searching text in body of db objects:

• select distinct object_name(id) from syscomments where text like '%Test To Searched%'

4. Updates in Joins, or updating table based on data.

• Update orderline set ord_date=y.Minorddate from orderline x (nolock), (select ord_invNo,min(ord_date) minorddate from orderline (nolock) where cust_id = 1000 group by ord_invNo ) y where x.cust_id = 1000 and x.ord_invNo = y.ord_invNo

5. This query will return a listing of all files in all databases on a SQL instance:

• EXEC sp_MSforeachdb 'USE ? SELECT ''?'', SF.filename, SF.size FROM sys.sysfiles SF'
  DBName E:\DataBase\DBName.mdf 288976DBName E:\Database\DBName.ldf 48568
  

Page Life Cycle:

Explain the life cycle of an ASP .NET page:
The very first step in the page lifetime is determining why the runtime is processing the page request.
There are various possible reasons:
1. Normal request
2. Postback
3. Cross-page postback,
4. Callback.

The page life cycle is articulated in three main stages:
1. Setup,
2. Postback,
3. Finalization.
Note that there are modifications to the process depending upon cross-page posts, script callbacks, and postbacks

1. The PreInit Event (No master and theme)

a. No master page and no theme have been associated with the page. Changing the master page or the theme
programmatically is possible only at this time.
b. Posted data is available, and all page controls have been instantiated and default to the properties
values defined in the ASPX source. (Note that at this time controls have no ID, unless it is explicitly
set in the .aspx source.)
c. IsCallback, IsCrossPagePostback, and IsPostback are set at this time.

2. The Init Event (Initialization, No view state)
a. The master page, if one exists, and the theme have been set and can't be changed anymore.
b. All child controls have their OnInit method invoked recursively. For each control in the control collection,
the naming container and a specific ID are set, if not assigned in the source. At this stage, the page
and controls typically begin loading some parts of their state.
c. The Init event reaches child controls first and the page later
d. At this time, the view state is not restored yet.

3. The InitComplete Event (Can write to view state)

a. For a page, only one operation takes place in between the Init and InitComplete events:
tracking of view-state changes is turned on. Tracking means persisting the view state values to some storage.
b. Any value written to the ViewState collection before InitComplete won't be available on the next postback.
In ASP.NET 1.x, you must wait for the Load event to start writing safely to the page or any control view state.

4. View-State Restoration (View state Restored)

a. If the page is being processed because of a postback—that is, if the IsPostBack property is true—the
contents of the __VIEWSTATE hidden field is restored.
b. At this stage, each control is given a chance to update its current state to make it identical to
what it was on last request
c. no event to wire up to handle the view-state restoration. If something needs be customized here,
you have to resort to overriding the LoadViewState method, defined as protected and virtual on the Control class.

5. Processing Posted Data (Posted or updated data is resorted)

a. Give control a chance to refresh its state in light of the posted data.

6. The PreLoad Event (System has done now it’s user’s turn)

a. the PreLoad event merely indicates that the page has terminated the system-level initialization phase
and is going to enter the phase that gives user code in the page a chance to further configure the page
for execution and rendering.
b. This event is raised only for pages.

7. The Load Event (Reflects the final state of controls so safe to access)

a. The Load event is raised for the page first and then recursively for all child controls.
b. At this time, controls in the page tree are created and their state fully reflects both the previous state
and any data posted from the client.
c. . At this time, access to control properties and view state is absolutely safe.
d. Handling Dynamically Created Controls
i. If the dynamic control has been re-created in the Load event, a match is now possible and the control can
refresh its state with posted data.

8. The LoadComplete Event (Page preparation is over now render)

a. The page-only LoadComplete event signals the end of the Page preparation phase.
b. It is important to note that no child controls will ever receive this event. After firing LoadComplete,
the page enters its rendering stage.
Page Finalization: After handling the postback event, the page is ready for generating the output for the browser.
The rendering stage is divided in two parts—
c. Prerendering
i. preprocessing and
ii. postprocessing.
d. Markup generation.

9. The PreRender Event (Final chance to update controls)

a. By handling this event, pages and controls can perform any updates before the output is rendered.
b. The PreRender event fires for the page first and then recursively for all controls.
c. Note that at this time the page ensures that all child controls are created. This step is important
especially for composite controls.

10. PreRenderComplete Event (Just to signal prerender is over)

a. Because the PreRender event is recursively fired for all child controls, there's no way for the page author
to know when the prerendering phase has been completed. – so this event

11. The SaveStateComplete Event (Save view state)

a. The next step before each control is rendered out to generate the markup for the page is saving the current state of the page to the view-state storage medium.
b. It is important to note that every action taken after this point that modifies the state could affect the rendering, but it is not persisted and won't be retrieved on the next postback.
c. the SaveStateComplete event occurs when the state of controls on the page have been completely saved to the persistence medium.
d. by overriding these two methods you can persist the page state in a server-side database or in the session state, dramatically reducing the size of the page served to the user.

12. Generating the Markup (Get markup for all controls)

a. Several overridable methods allow control developers to intervene in various steps during the markup generation
b. No user event is associated with the rendering phase.

13. The Unload Event (unload but not disposed)

a. The rendering phase is followed by a recursive call that raises the Unload event for each control, and finally for the page itself
b. Note that the unload notification arrives when the page or the control is being unloaded but has not been disposed of yet
c. Overriding the Dispose method of the Page class, or more simply handling the page's Disposed event, provides the last possibility for the actual page to perform final clean up before it is released from memory.

What's Your Type:

DELEGATES:

• Delegates are type safe mechnism for call back functions.
• Call back can be static or Instance methods.
• Represent the address of a function
• Allow co-variance and contravariance (C# and .net allow these for reference types not for value type or Void)
• Covariance - return type can be derived from delegate's return type
• Contravariance - Mthd parameter can be the base of delegate parameters. for ex:

delegate object MyCallback(Filestream s);

string delegateInstance(stream s); - valid.

int delegateInstance(stream s); - not valid as int is value type

• Ultimately delegates are classes. So they can be defined anywhere a class can be defined. delegate:Multicastdelegate:system.Object.
• Compiler create a class for any defined delegate with four methods - constructor, Invoke, BeginInvoke and EndInvoke. Properties of multicast delegtes are _target (referes to object to operate on. In static method it is null) ,_methodPtr (mthd to callback) and _invocationList (refers to array when delegate chain is used else null).
• When chain of delegate is used and callback methods return some value, then finally return value of last callback method is returned. To control invocation and get all return values we have to manually loop delegate array and process it.
  

EVENTS:

• It's special Type which provide notification capabilities to a member defining this type.
• Based on delegates.
• By default event is based on delegate type which takes two parameters (object sender,EverntArgs e)