SQL Server 2014 CTP1 installation Step By Step

Lets check for a quick step by step installation guidelines of SQL Server 2014 CTP1 on Windows Server 2012 Datacenter edition.

• Click on Installation option to start installation of a new instance of SQL Server 2014 CTP1 edition, alternatively , you can upgrade from SQL server 2012 SP1 instance from Update section.

• Specify Evaluation edition of SQL Server 2014 CTP 1 version.

• Lets select the features available required for SQL Server 2014 CTP1 standalone instance.

• Click on Next in order to start the ‘Installation Rule Engine‘ for SQL Server 2014.

• Specify the instance name of the SQL instance.

• Next , specify the authentication mode & setup password for SQL Server authentication.

• As you can see , in SQL Server 2014 CTP1 , there is default checking of Collation settings for Database Engine & Analysis Services. You can customize it.

• Next, specify settings for SSAS 2014 & SSRS 2014.

• Finally , execute the instance configuration rules & start installation.

• After installation , click on SSMS 2014 CTP 1 & login with your Windows Authentication/SQL Server Authentication credentials.

• Also, you can work with your Windows Azure SQL database too with SQL Server Management Studio 2014 CTP1 , you can login in with SQL Azure database credentials from SSMS 2014.

47.673988 -122.121512

About these ads

Onlinr Hadoop Tutorial Videos Free

http://meta-guide.com/videography/100-best-hadoop-tutorial-videos/

Java Begineers

Java Begineers vedios

What changes have been made on the PMBOK 5th Edition?

Without going into details, here’s a list of the major changes:

 

Addition of a new knowledge area called ‘Stakeholder Management’ (going from 9 to 10 Knowledge areas)

 

ASP.Net Page Life Cycle Events:

ASP.Net Page Life Cycle Events:

At each stage of the page life cycle, the page raises some events, which could be coded. An event handler is basically a function or subroutine, bound to the event, using declarative attributes like Onclick or handle.

Following are the page life cycle events:

• PreInit . PreInit is the first event in page life cycle. It checks the IsPostBack property and determines whether the page is a postback. It sets the themes and master pages, creates dynamic controls and gets and sets profile property values. This event can be handled by overloading the OnPreInit method or creating a Page_PreInit handler.
• Init . Init event initializes the control property and the control tree is built. This event can be handled by overloading the OnInit method or creating a Page_Init handler.
• InitComplete . InitComplete event allows tracking of view state. All the controls turn on view-state tracking.
• LoadViewState . LoadViewState event allows loading view state information into the controls.
• LoadPostData . during this phase, the contents of all the input fields defined with the

  tag are processed.
• PreLoad . PreLoad occurs before the post back data is loaded in the controls. This event can be handled by overloading the OnPreLoad method or creating a Page_PreLoad handler.
• Load . the Load event is raised for the page first and then recursively for all child controls. The controls in the control tree are created. This event can be handled by overloading the OnLoad method or creating a Page_Load handler.
• LoadComplete . the loading process is completed, control event handlers are run and page validation takes place. This event can be handled by overloading the OnLoadComplete method or creating a Page_LoadComplete handler.
• PreRender . the PreRender event occurs just before the output is rendered. By handling this event, pages and controls can perform any updates before the output is rendered.
• PreRenderComplete . as the PreRender event is recursively fired for all child controls, this event ensures the completion of the pre-rendering phase.
• SaveStateComplete . state of control on the page is saved. Personalization, control state and view state information is saved. The HTML markup is generated. This stage can be handled by overriding the Render method or creating a Page_Render handler.
• UnLoad . the UnLoad phase is the last phase of the page life cycle. It raises the UnLoad event for all controls recursively and lastly for the page itself. Final cleanup is done and all resources and references, such as database connections, are freed. This event can be handled by modifying the OnUnLoad method or creating a Page_UnLoad handler.

• ASP.Net Page Life Cycle:

  When a page is requested, it is loaded into the server memory, processed and sent to the browser. Then it is unloaded from the memory. At each of this steps, methods and events are available, which could be overridden according to the need of the application. In other words, you can write your own code to override the default code.
  The Page class creates a hierarchical tree of all the controls on the page. All the components on the page, except the directives are part of this control tree. You can see the control tree by adding trace= "true" to the Page directive. We will cover page directives and tracing under 'directives' and 'error handling'.
  The page life cycle phases are:
  • Initialization
  • Instantiation of the controls on the page
  • Restoration and maintenance of the state
  • Execution of the event handler codes
  • Page rendering
  Understanding the page cycle helps in writing codes for making some specific thing happen at any stage of the page life cycle. It also helps in writing custom controls and initializing them at right time, populate their properties with view-state data and run control behavior code.
  Following are the different stages of an ASP.Net page:
  • Page request . when ASP.Net gets a page request, it decides whether to parse and compile the page or there would be a cached version of the page; accordingly the response is sent
  • Starting of page life cycle . at this stage, the Request and Response objects are set. If the request is an old request or post back, the IsPostBack property of the page is set to true. The UICulture property of the page is also set.
  • Page initialization . at this stage, the controls on the page are assigned unique ID by setting the UniqueID property and themes are applied. For a new request postback data is loaded and the control properties are restored to the view-state values.
  • Page load . at this stage, control properties are set using the view state and control state values.
  • Validation . Validate method of the validation control is called and if it runs successfully, the IsValid property of the page is set to true.
  • Postback event handling . if the request is a postback (old request), the related event handler is called.
  • Page rendering . at this stage, view state for the page and all controls are saved. The page calls the Render method for each control and the output of rendering is written to the OutputStream class of the Page's Response property.
  • Unload . the rendered page is sent to the client and page properties, such as Response and Request are unloaded and all cleanup done.

MSBI Session

SSIS Training Session Part 1- http://www.youtube.com/watch?v=C75p1199pmQ
SSRS Detailed Sessions Part 20 http://www.youtube.com/watch?v=KrJqsirQCLw
SSRS with MDX Part 2 http://www.youtube.com/watch?v=RsR-AZD1u4U

Baseless Merge with TFS 2010

In VS 2012 we got UI for Baseless code merge But for VS2010 we need to use command line tool.

When you would like to use Source Control Merge Wizard in Visual Studio (e.g.; by right clicking a branch folder then going to 'Branching and Merging' -> 'Merge') and you find that the intended target is not in the 'Target branch' selection that means the source does not have any relationship with the target. You can proof this from 'Branching and Merging' -> 'View Hierarchy' option. This is when we need to do baseless merge operation.

 To perform this operation, we can use the merge command on TFS command line tool. The syntax is

Tf merge /baseless /recursive /version:[versionspec] [source path] [target path] 

- path can be physical folder or source control location.
- [versionspec] can be a changeset, range of (inclusive) changesets separated by '~' character, a label, a date or versions. If we don't specify /version then it will merge all changes.

Below are some examples:
- Merge all changes from branch to trunk

D:\My_Project>tf merge /baseless /recursive "$/My Project/branch/one" "$/My Project/trunk" 

- Merge all changesets up to changeset 1000

D:\My_Project>tf merge /baseless /recursive /version:1000 "$/My Project/branch/one" "$/My Project/trunk" 

- Merge only changeset 1000

D:\My_Project>tf merge /baseless /recursive /version:1000~1000 "$/My Project/branch/one" "$/My Project/trunk" 

- Merge changesets 1000 to 1010 inclusively

D:\My_Project>tf merge /baseless /recursive /version:1000~1010 "$/My Project/branch/one" "$/My Project/trunk" 

If it is happened that the merge causing a lot of checkouts of unmodified files then we can use TFS Power Tools to undo the checkouts.

D:\My Project\trunk>tfpt uu /r /noget *

'uu' - undo unchanged
'/r' - recursive
'/noget' - do the operation without getting latest


If this one is still not working and leaving a lot of unmodified files checked out, we have to do Undo Changes manually. This can be done through the Pending Changes view, right click on any file from the list then select 'Undo'. The Undo Pending Changes dialog will pop up. Check all the files then click 'Undo Changes' button. A confirmation dialog with the message "... has changed. Undo check-out and discard changes?' will be shown. Click 'No to All' button. Then all unmodified files will be reverted while the modified ones from the merge operation stay.

Tracing in Windows Communication Foundation

Tracing mechanism in Windows Communication Foundation is based on the classes that resides in System.Diagnostic namespace.Important classes are Trace, TraceSource and TraceListener.

Following are the steps to enable tracing in WCF:

1. Configuring WCF to emit tracing information/Define Trace Source, we have the following options:

• System.ServiceModel 
• System.ServiceModel.MessageLogging 
• System.ServiceModel.IdentityModel
• System.ServiceModel.Activation 
• System.Runtime.Serialization 
• System.IO.Log
• Cardspace

      In configuration file, we will define a source to enable this configuration as follows:

     

2. Setting Tracing Level, we have the following available options, we need to set this tracing level to available options other than default "Off":

• Off
• Critical
• Error
• Warning
• Information
• Verbose
• ActivityTracing
• All

      In configuration file, we can choose above values for switchValue attribute as follows:

                                     switchValue=”Information”>

3. Configuring a trace listener

    For configuring a trace listener, we will add following to config file.
    
                                  type="System.Diagnostics.XmlWriterTraceListener"
                 initializeData="d:\logs\messages.svclog" />
      

4. Enabling message logging

     
        
                                logEntireMessage="true"
                    logMalformedMessages="false"
                    logMessagesAtServiceLevel="true"
                    logMessagesAtTransportLevel="false"
                    maxMessagesToLog="3000"
                    maxSizeOfMessageToLog="2000"/>
        
    

logEntireMessage: By default, only the message header is logged but if we set it to true, entire message including message header as well as body will be logged.
logMalformedMessages: this option log messages those are rejected by WCF stack at any stage are known as malformed messages.
logMessagesAtServiceLevel: messages those are about to enter or leave user code.
logMessagesAtTransportLevel: messages those are about to encode or decode.
maxMessagesToLog: maximum quota for messages. Default value is 10000.
maxSizeOfMessageToLog: message size in bytes.

Putting all this together, configuration file will appear like this.

--------------------------------------------------------------------------- 

   

   

     

       

         

               type="System.Diagnostics.XmlWriterTraceListener" initializeData="d:\logs\myMessages.svclog">

       

     

   

 

           

     

       

                        logMessagesAtServiceLevel="false"

                        logMessagesAtTransportLevel="false"

                        logMalformedMessages="true"

                        maxMessagesToLog="5000"

                        maxSizeOfMessageToLog="2000">         

       

     

   

---------------------------------------------------------------------------

Note: In this case, information will be buffered and not published to file automatically, So, we can set the autoflush property of the trace under sources as follows: