Guide to Setting up SharePoint Virtual Dev Environment

Setup
This assumes that you’ll be using a virtual server type of software (Virtual PC, Virtual Server, or VMWare). Makes no difference but I prefer Virtual PC for now as I can drag and drop files from my desktop into it. Virtual PC and Virtual Server images are compatible so you can build in VPC and use it in Virtual Server if you want. I generally give the VM 1–2GB of RAM as its going to be running everything (Windows Server, SQL, SharePoint, Visual Studio, etc.) so it’ll need it (1GB when I run on my laptop which has a max of 2GB, and 2GB to the VM when I run on my desktop which has a max of 4GB).

I generally don’t keep source code in my VM (or it’s very temporary, say for demos) so I keep it generally on an external drive. This drive is shared to the VM as the Z:. Also keep your VHD files (Virtual Hard disk, or whatever VMWare uses) on an external drive. Mucho better performanco.

Also this a workgroup install rather than a domain controller. Some people like having a DC running with SharePoint but I like to keep it separate. You can also spin up a domain controller VM and connect the machine to the domain through the local network later.

Installing
Okay, here’s the rundown of what gets installed. Some things can be shifted around in order of preference, but obviously you can’t install SharePoint before you install SQL Server. Again, feel free to move things around as you see fit.

No detailed instructions for installing most of this (but feel free to ask for clarification on anything, as some of it might not make much sense). Just follow the wizards entering whatever information is needed and you can generally accept the defaults. Really, it’s not that complicated. Also I make things easy for development like creating a single user for everything and just giving them admin rights to the box. In a real setup you would have domain accounts and only grant them the rights they need in SQL Server. I just find having as few things possible make it easier for development (and we’ll worry about configuration later in the test/production environment).

Windows Setup

Install Windows Server 2003 Standard Edition. Any edition will do, but this one works fine.
Install Windows Server 2003 Service Pack 1
Create local spadmin account on the machine. Add to the Local Administrators group. This will be used for all portal functions.
Create local spuser account on the machine. You can use this as a reader or contributor on your sites for testing (and feel free to create more, but I find two is enough)
Setup IIS. Just the basic options are needed here.

Remove event tracker shutdown dialog. What a PITA this thing is for development.
I prefer to browse to http://machinename rather than http://localhost. Add machinename to trusted sites in IE for this to work. This will eliminate the NT challenge/response dialog when you browse to the site, and all urls will be better formed.
Edit the command prompt to add QuickEdit. Just handy when copying/pasting things like wp part packs in the command window.
Mail Server

Install hMailServer. This is a free (open source) SMTP/POP3 server that I use instead of Exchange. Lightweight and free. Alternately you can install Exchange if you really want to.
Add a catch all account to the mail server – admin@yourdomain.com. This will be used for any mail to/from the Portal or WSS sites.
Add user account – username@yourdomain.com. This is attached to the user account for the portal (or you can use admin for everything)

SQL Server

Install SQL 2000. Standard OOTB install, configure it to run in mixed mode. I use SQL instead of the built in MSDE so I do testing with full text searches.
Install SQL 2000 SP4.

SharePoint Install

Install SharePoint Portal Server 2003 without the database engine. We’ll connect it to SQL during setup phase.
Configure and create the initial portal. Name it whatever you want like “Development Portal”, “My Little Pony”, “Big Man Hands”, whatever.
Use the spadmin account name you created above for all operations.
Use localhost for the mail server.
Give spadmin email address of admin@yourdomain.com.
Add machinename\spuser (spuser@yourdomain.com) as reader to the portal.
Install WSS SP2. Have to install this before we install SPS SP2.
Install SPS SP2.
Add shortcut to 60 HIVE directory on desktop or QuickLaunch. I just find it a pain to navigate down the ugly tree anytime I need to hit the directory in Explorer so having a folder that goes directly there is handy.
Add STSADM dir to path in command prompt. I find this very handy so I can open up a command prompt and just start typing STSADM rather than the full path. Optionally you can install STSADMWin or whatever. I’m just a command prompt kinda guy

IIS Configuration

Change WSS_Minimal in web.config to Full. This is required to set debugging=true and makes life easier.
Set debug=true in compilation section of web.config for debugging Web Parts

Visual Studio Setup

Install and Configure Visual Studio 2003. I just select the default which includes C# and VB.NET but you do whatever works for you.
Copy keyboard shortcuts (so ReSharper can install, if you’re installing it)\
Install Web Part Templates for Visual Studio .NET. These are the templates for creating new Web Part Library projects.
Install ReSharper. Set the persistence to use the local drive (this is for performance of local files vs. remote). I prefer ReSharper but some like CodeRush, Refactor Pro!, and other tools.
Install GhostDoc. I use this for creating stub documents for APIs and Web Parts that I’ll be sharing.
Install TestDriven.NET. Killer app for TDD and running unit tests. Also includes NCover now.

SharePoint Tools

Copy InstallAssemblies (from the Web Part Toolkit) to server and add to QuickLaunch. You just need the EXE and I like having it on the QuickLaunch taskbar as I can just click on it and install a web part quickly.
Install SharePoint Explorer. Best tool for looking at what you have.
Install SmartPart (if you’re planning to do development via User Controls)
Office 2003

Install Office 2003
Install FrontPage 2003
Install Other Tools

TopStyle : I use this for editing CSS files but feel free to use Visual Studio (blech) or your own CSS editor (Notepad anyone?)
XmlSpy : This comes with a cost, but it’s worth it for Xml editing. There are some less expensive packages and then there’s always… Notepad!
IE Dev Toolbar : Very handy for debugging pages and poking around in SharePoint sites.
Notepad++/Notepad2. I prefer these over the standard Notepad.
Paint.Net if you plan on making your own icons or graphics. Free and written in .NET!
SysInternals BGInfo. I have this in my startup for the server as it shows me what the server name is, IP, and other info that is handy when you’re flipping around between machines.
Plus any other tools you like. Scott Hanselman’s list here is a great resource.

Testing

Create a new web part using the template (Hello World or something)
Install using InstallAssemblies. This will add it to the bin dir and create the SafeControl entries in web.config so the web part will work correctly.
Add the web part to a page somewhere.
Run Web Part project in Visual Studio with debugging to make sure debugging works
Create an alert, open up Outlook Express and configure it to use your local mail server (if you installed it). You should receive an alert.

Security and Source Code

When working in a VM you generally do NOT want your source code to be in the VM (just in case it turfs and you can’t recover it) so I keep all my source on an external drive (rather than say the host drive as I move from place to place). I also only have it set to use Local networking meaning it can’t see out and I can’t see in (which is why I prefer Virtual PC so I can drag/drop files to the VM). This allows me to have a domain controller on the local network if I need it.

With Virtual PC you can share this drive as a network drive letter inside the VM (my external drive is always Z:. In order to open files and not get the dreaded “the project location is not fully trusted” you need to fix security policy if you want to open files from a network drive. Google "the project location is not fully trusted" and you’ll get a ton of answers. Problem is that none of these work for a drive that is mapped into a VM. A drive shared shows up in the Intranet Zone. Bizzare huh? Means you have to trust the entire internet zone. Not a good thing. Can’t use z:\\, have to use file:// but there is no file:// for a mapped drive (because there is no server name).

James Kovacs says to use ZoneStripper but I really don’t want to do this with each project so the technique below works well:

Open the ".NET Framework Configuration" utility
Expand "Runtime Security Policy->Machine->Code Groups"
Right click "All Code", and then select the "New..." item
Type a name in the "Name" textbox (like “VS Projects on Z:“ or something), and then click the "Next" button
Set the condition type to "URL" and type the following string to the "URL:" textbox: “file://Z:/*”
Click the "Next" button and assign the "FullTrust" permission set to this Code Group.
This will trust all code on Z: and not display the dialog. You can also use file://servername/* but since we’re working with a drive letter here, we don’t have a server name.

I also run regular scheduled backups of my external drive to whatever host it’s connected with using SyncToy so I generally always have 3 copies around (1 on laptop, 1 on desktop, 1 on drive) and do make weekly DVD backups of the source and CVS trees.

Tips and the Afterlife

After your environment is setup, all the tools are running, and you’re happy with what you have created SAVE IT! Snapshot that puppy so you can come back to it. Some people might prefer to use undo disks but again, I find these sometimes have issues so I just copy the whole dang VHD file as an archive in case the worst happens.
Setup a Development Area in the Portal. Two things I do as a final step in getting things up and running on the portal. If I installed SPS then I create an area called Development. This is just a collection of sub-areas for various projects, spike web parts, whatever. It leaves the rest of the default portal setup intact as I don’t need to build a taxonomy that represents a production site or anything. If I need something like that (for example to demo what a sample navigation structure might look like) I’ll just create a new Virtual Server in IIS and create a portal off it. I keep the main portal on port 80 for general development.
Another thing I do is copy the STS definition and create a new STSDEV site def from this. Not much is changed in the definitions but I do go in and add a top and bottom zone to the default.aspx page. This lets me a) screw around with any list definitions without touching the default STS one and b) have some extra zones to mess with in case I want them. I also setup 10 pages in the default module which are copied at creation time. These are placeholder pages (copied from default.aspx) which I can use instead of web part pages and are ghosted so I don’t worry about them showing up in something like Ghost Hunter. Finally I create a new site called Sandbox using this config and add it to my Development section in SPS as a listing to quickly get to it. For most web parts, I develop them so they work in both a SPS area and a WSS site (unless it has SPS specific stuff).
Okay, now go start using your portal for development. It’s complete, self-sufficient, and have fun

Setting Up SharePoint To Use MSSQL Server

This post gives you information on how to install Microsoft Windows SharePoint Services on your Windows 2003 web servers.

According to Microsoft, Windows SharePoint Services technology "is an integrated portfolio of collaboration and communication services designed to connect people, information, processes, and systems both within and beyond the organizational firewall. SharePoint sites provide a central repository for documents, information, and ideas, and enable users to work interactively with these items."

Currently we support Windows SharePoint Services v2 with Service Pack 2. Support for later versions is coming soon.

Pre-Installation Requirements
SharePoint Installation and Configuration
Install MSSQL Server
Select Authentication Mode for SQL Server
Install SharePoint
Configure H-Sphere to use SharePointB

Pre-Installation Requirements
Before you install Microsoft Windows SharePoint Services on your Web server, make sure that you have installed the required hardware and software.

Required Details
Important: SharedPoint and MSSQL should be installed on one and same physical server.
Server Hardware Intel Pentium III (and later) compatible processor
CPU/550 MHZ 1 CPU (2 recommended)
512 MB RAM

Operation System Microsoft Windows Server 2003:
Standard Edition
Enterprise Edition
Datacenter Edition

Server Software
(Web application server) NTFS file system
Microsoft ASP.NET
Internet Information Services in IIS 6.0 worker process isolation mode with the SMTP service

Server Databases* Microsoft SQL Server 2000 Service Pack 3 or later**
Microsoft SQL Server 2005

Browser Client Microsoft Internet Explorer 5.01 or later
Microsoft Internet Explorer 5.5 or later
Netscape Navigator version 6.2 or later
Mozilla 1.4 or later


* Microsoft Windows SharePoint Services SQL Server 2000 Desktop Engine (WMSDE) is not supported by H-Sphere


SharePoint Installation and Configuration
To install and configure SharePoint Services, follow the procedure:

Step 1: Install MSSQL Server
Prior to installing SharePoint, you need to install MSSQL Server. You can chose between:

MSSQL Server 2000
MSSQL Server 2005
Step 2: Select Authentication Mode for SQL Server
In order to allow Windows SharePoint Services to connect to your SQL Server database, it is recommended that you configure the SQL Server database to use Windows authentication.

For SQL Server 2000:

On your server computer, go to Start -> All Programs -> Microsoft SQL Server -> Enterprise Manager.
In Enterprise Manager, click the plus sign (+) next to Microsoft SQL Servers.
Click the plus sign (+) next to the SQL ServerGroup.
Right-click the SQL Server name, and go to Properties.
In the Properties dialog box, click the Security tab.
In the Authentication section:
If you want use the MSSQL Server only for Microsoft Windows SharePoint Services, select only Windows Authentication mode.
If you want use the MSSQL Server both for Microsoft Windows SharePoint Services and hosting, select SQL Server and Windows Authentication mode.
Click OK.
Note: If you have used a domain account that does not already have database creation rights in SQL Server, you can give the account this access using Enterprise Manager in SQL Server 2000, as a temporary solution.

For SQL Server 2005

On your server computer, go to Start -> All Programs -> Microsoft SQL Server 2005 -> SQL Server Management Studio.
On the Connect to Server screen, select the name of the local server from the Server name drop-down list.
On the Server Properties - Server name screen, click Security in the Select a page section.
In the Server Authentication section:
If you want use the MSSQL Server only for Microsoft Windows SharePoint Services, select only Windows Authentication mode.
If you want use the MSSQL Server both for Microsoft Windows SharePoint Services and hosting, select SQL Server and Windows Authentication mode.
Click OK.
Note: If you have used a domain account that does not already have database creation rights in SQL Server, you can give the account this access using SQL Server Management Studio, as a temporary solution.

Step 3: Install SharePoint
By default, when you install Windows SharePoint Services, the Setup program installs WMSDE (Microsoft Windows SharePoint Services SQL Server Desktop Engine).
H-Sphere doesn't support WMSDE. To use SharePoint with SQL Server, run Setup with the Server Farm option. Server Farm option allows supporting a larger set of Web sites.

Download and install SharePoint

WARNING:
During SharePoint setup, you may get the error when connecting to http://localhost:SharePointPort/. To solve it, you should remove the string from
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\template\admin\1033\web.config.

Also please check the Authentication Methods for SharePoint Central Administration WebSite in IIS. And if Basic authentication is disabled, enable it.

Go to SharePoint Central Administration:
Start/Settings/Control Panel/Administrative Tools/SharePoint Central Administration
Configure Administrative Virtual Server in the Server Configuration tab:
Select Use an existing application pool and chose StsAdminAppPool
Go to Security Configuration and select NTLM
Click OK
Configure Database Server in the Server Configuration tab:
Select Database Server and enter your MSSQL Server IP or MSSQL instance
In SQL Server database name enter your SharePoint Main DB NAME
Set Windows authentication
In Active Directory Account Creation chose Users already have domain accounts. Do not create active directory accounts.
Click OK
Step 4: Configure H-Sphere to use SharePoint
If you installed Microsoft Windows SharePoint Services after H-Sphere is updated, run the H-Sphere updater again.
Open HSphere.config file usually located in the {disk}\Hsphere.Net\bin\ directory and make sure the correct name of your MSSQL server was set in the SharePoint resource setting during H-Sphere update.
Restart H-Sphere service
net stop hsphere
net start hsphere

Links for more resource

Category Online Location Windows SharePoint Services 3.0 Overview
http://office.microsoft.com/sharepointtechnology

Windows SharePoint Services TechCenter
http://www.microsoft.com/technet/windowsserver/sharepoint/default.mspx

Office SharePoint Server 2007
http://office.microsoft.com/sharepointserver

Office SharePoint Designer 2007
http://office.microsoft.com/sharepointdesigner

Composite UI Application Block

This application block is a reusable, source code–based component based on the Microsoft .NET Framework 2.0. It provides proven practices to build complex smart client user interfaces based on well known design patterns such as the Composite pattern, in which simple user interface parts can be combined to create complex solutions, but at the same time allowing these parts to be independently developed, tested, and deployed.

The Composite UI Application Block is designed to help you build these complex, enterprise-ready Windows Forms–based solutions. It provides a proven architecture and implementation that helps you to build applications using the common patterns found in line-of-business front-end applications.

Common Scenarios

The application block is designed to support the development of smart client line-of-business applications such as the ones found in the following scenarios:

* Online transaction processing (OLTP) front-ends, in areas such as stock distribution centers or data entry applications
* Rich client portals to back-end services, such as portals to government services or bank teller applications
* UI intensive information-worker standalone applications, such as those used by call center staff, IT support desks, or stock traders

All these scenarios require rich user interaction, a shell architecture that can host the user interface and business logic "parts," and varying degrees of centralized control of the functionality and behavior that the application exposes to its users.

The Composite UI Application Block facilitates the design and implementation of your client applications in three areas:

* It allows your application to be based on the concept of modules or plug-ins.
* It allows developers with shell expertise to build components that hide user interface complexity from the business logic development.
* It facilitates development using patterns for loose coupling between modules.

Design Goals

The design of the Composite UI Application Block is based around three main areas:

* Finding and loading modules at application initialization to dynamically build a solution
* Separating development requiring user interface and shell expertise from pure business logic development
* Achieving re-use and modularity of your code by helping with common techniques used for loose coupling

Finding and Loading Modules

A key goal of the Composite UI Application Block is to support the development of applications through the use of independent, but collaborating, modules. This is achieved by:
* An implementation of a catalog that specifies which modules to load.
* A module loader that actually loads and initializes the modules that comprise your application.

These implementations can be customized for your own needs without changing the provided core Composite UI Application Block implementation because all of the main subsystems work as plug-ins. For example, your application could obtain the list of modules to be loaded for a particular user of the application from a centrally managed Web service instead of reading them from a file.

Consolidating User Interface and Shell Expertise

Seldom does every developer of an application have both knowledge of the business logic requirements and deep expertise in user interface or shell development. In large projects, productivity and consistency can be achieved if the developers with expertise in building shells can build reusable components encapsulating that knowledge.

The Composite UI Application Block provides an architecture around these components and an implementation based on Windows Forms. It includes:
* A consistent way of showing and hiding controls using Workspaces. A shell developer can consistently introduce visual effects, layout strategies, or other behaviors without affecting the business logic components.
* A common way of adding and using UIElements into the shell, such as menu items, status bars, so that the developer of an individual piece of business logic does not need to know how or where that element will be shown.
* A Command architecture that allows a business logic developer to separately define actions a user can take and how they are displayed in a specific shell.

Achieving Modular Design of Your Business Logic

The functionality that focuses on helping you achieve loose coupling between your modules includes:

* WorkItems that provide an easy way to scope which collaborating components participate in a use case, share state, events, and common services.
* An Event Broker that provides a many-to-many, loosely coupled event system mechanism between objects in your application.
* Placeholders for sharing State where multiple components can place or retrieve information.

Inherent Extensibility

Internally, the design is based on concepts of services (components that provide an implementation of functionality) and containers (components that hold references to your objects containing business logic, controls, and services). The Composite UI Application Block's extensibility mechanism allows you to add and extend it with your own behaviors and services in the same way it implements its functionality.

Getting Started

The Composite UI Application Block has been developed as a result of analyzing common enterprise development challenges and successful solutions to these challenges. However, because each application is unique, you will have to analyze whether this application block is suitable for your particular needs. To evaluate this application block and determine its applicability to your projects, it is suggested that you dedicate at least half of a day to explore the application block. The following is a suggested evaluation approach:

* Download the code and documentation in the language of your preference.
here is the link to download http://www.microsoft.com/downloads/details.aspx?FamilyId=7B9BA1A7-DD6D-4144-8AC6-DF88223AEE19&displaylang=en
* Install the Composite UI Application Block and compile it.
* Read the "Introduction" and "Scenarios and Goals" sections of the documentation.
* Compile and run the QuickStart samples.
* Start with the "Walkthrough - Designing and Building a CAB Application" QuickStart and read the related documentation.

In next article i will consentrate diffrent types of blocks and their utilities. Keep have a lok on the blog to find some thing interesting :)

Setting up your SharePoint 2007 Development Environment

One of the problems with SharePoint development quite simply: you need SharePoint in order to develop. There is always the scenario where you take the DLLs from the SharePoint server, copy them to your XP machine and you tinker around until you get something manageable. I knew people that did this very thing, and they had extremely complex batch files that would deploy from their development machine, then they'd go to the SharePoint server, run iisreset, hit refresh, pray, and then wonder why they had so much trouble debugging.
First and foremost, you need Windows Server 2003 R2. If you can spare a physical box then that's an ideal situation just because of the sheer amount of crap you're going to install on this server, but I have used VMware and Virtual PC as well. If you're going the virtualization route, VMware seems to be the more robust solution and also seems to run much faster than VPC (and no, I don't work for VMware :)).

Second - install Microsoft SQL Server 2005 Developer Edition. You don't need to install Analysis Services or Reporting Services, but you might find yourself using Notification Services or the Service Broker at some point, so install Notification Services.

Thirdly, you need Microsoft Office SharePoint Server 2007. Don't bother installing WSS v3.0 without MOSS. As a developer, you want the full boat, and you'll need it for all the powerful enterprise features like Excel Services, the Business Data Catalog, etc. When you install this, do not install the standalone copy. You want to create a single-server farm and point your content and configuration databases at the SQL Server instance. The reason for this is that MOSS running on top of MSDE is quite possibly one of the most horribly performing application combinations I've ever seen, and your dev environment will screech to a grinding halt in Standalone mode.
Next, you need Visual Studio 2005 - at least Professional, but if you've got an MSDN subscription you might as well install the full boat. Also, if you're doing this for your company, you might want to consider installing the TFS client so you can check your SharePoint code in and out of Team Foundation Server. That's right - I actually said there was a good way of source-controlling SharePoint code - something that has been lacking in all previous versions of it.
So, to recap, setting up your development environment involves the following, in this order:
Prep your environment - either set up your VM or format your physical box
Install Windows Server 2003 R2 , make sure you include the latest service pack
Configure your server as an application server
Install IIS
Install the SMTP service
Install Microsoft SQL Server 2005 Developer Edition
Install Microsoft .NET Framework 3.0 runtime. Feel free to install the SDK too.
Install Microsoft Office SharePoint Server 2005 not in standalone mode!!!
Install Microsoft Visual Studio 2005
Optionally install the Team Explorer client to allow you to get source control access for all your SharePoint code
Install the SharePoint Extensions for WSS v3.0 from Microsoft. These will give you VS templates for web parts that are priceless for Web Part developers, as well as some stuff for doing solutions, features, and even site definitions. Get these!
Install the Enterprise Content Management Starter Kit from Microsoft. Its not currently available in anything other than beta 2 format, but it should be released any day now. This is the toolkit that contains the VS 2005 templates for creating real workflows, not the one-off instanced workflows you create with SharePoint Designer 2007.

You will also want to find some migration path from your environment to a staging or testing environment, but the rest of those details are specific to your organization and your environment. If you create your SharePoint environment using the preceding steps and resign yourself to knowing the fact that you will be developing on Windows Server 2003 for all of your SharePoint work (unless you're doing Web Services, in which case any client environment will do) - then you should be off and running.

SQL Server optimization Tips

As per my research some are the tips that I collected for Sql Server optimization ...here we go..

* Use views and stored procedures instead of heavy-duty queries. This can reduce network traffic, because your client will send to server only stored procedure or view name (perhaps with some parameters) instead of large heavy-duty queries text. This can be used to facilitate permission management also, because you can restrict user access to table columns they should not see.

* Try to use constraints instead of triggers, whenever possible. Constraints are much more efficient than triggers and can boost performance. So, you should use constraints instead of triggers, whenever possible.

* Use table variables instead of temporary tables. Table variables require less locking and logging resources than temporary tables, so table variables should be used whenever possible. The table variables are available in SQL Server 2000 only.

* Try to use UNION ALL statement instead of UNION, whenever possible. The UNION ALL statement is much faster than UNION, because UNION ALL statement does not look for duplicate rows, and UNION statement does look for duplicate rows, whether or not they exist.

* Try to avoid using the DISTINCT clause, whenever possible. Because using the DISTINCT clause will result in some performance degradation, you should use this clause only when it is necessary.

* Try to avoid using SQL Server cursors, whenever possible. SQL Server cursors can result in some performance degradation in comparison with select statements. Try to use correlated sub-query or derived tables, if you need to perform row-by-row operations.

* Try to avoid the HAVING clause, whenever possible. The HAVING clause is used to restrict the result set returned by the GROUP BY clause. When you use GROUP BY with the HAVING clause, the GROUP BY clause divides the rows into sets of grouped rows and aggregates their values, and then the HAVING clause eliminates undesired aggregated groups. In many cases, you can write your select statement so, that it will contain only WHERE and GROUP BY clauses without HAVING clause. This can improve the performance of your query.

* If you need to return the total table's row count, you can use alternative way instead of SELECT COUNT(*) statement. Because SELECT COUNT(*) statement make a full table scan to return the total table's row count, it can take very many time for the large table. There is another way to determine the total row count in a table. You can use sysindexes system table, in this case. There is ROWS column in the sysindexes table. This column contains the total row count for each table in your database. So, you can use the following select statement instead of SELECT COUNT(*): SELECT rows FROM sysindexes WHERE id = OBJECT_ID('table_name') AND indid < 2 So, you can improve the speed of such queries in several times.

* Include SET NOCOUNT ON statement into your stored procedures to stop the message indicating the number of rows affected by a T-SQL statement. This can reduce network traffic, because your client will not receive the message indicating the number of rows affected by a T-SQL statement. This can results in good performance benefits, because SQL Server will return to client only particular rows, not all rows from the table(s). This can reduce network traffic and boost the overall performance of the query.

* Use the select statements with TOP keyword or the SET ROWCOUNT statement, if you need to return only the first n rows. This can improve performance of your queries, because the smaller result set will be returned. This can also reduce the traffic between the server and the clients.

* Try to restrict the queries result set by returning only the particular columns from the table, not all table's columns. This can results in good performance benefits, because SQL Server will return to client only particular columns, not all table's columns. This can reduce network traffic and boost the overall performance of the query.
1.Indexes
2.avoid more number of triggers on the table
3.unnecessary complicated joins
4.correct use of Group by clause with the select list
5 In worst cases DenormalizationIndex Optimization tips

* Every index increases the time in takes to perform INSERTS, UPDATES and DELETES, so the number of indexes should not be very much. Try to use maximum 4-5 indexes on one table, not more. If you have read-only table, then the number of indexes may be increased.
* Keep your indexes as narrow as possible. This reduces the size of the index and reduces the number of reads required to read the index.
* Try to create indexes on columns that have integer values rather than character values.
* If you create a composite (multi-column) index, the order of the columns in the key are very important. Try to order the columns in the key as to enhance selectivity, with the most selective columns to the leftmost of the key.

* If you want to join several tables, try to create surrogate integer keys for this purpose and create indexes on their columns.

* Clustered indexes are more preferable than nonclustered, if you need to select by a range of values or you need to sort results set with GROUP BY or ORDER BY.

* If your application will be performing the same query over and over on the same table, consider creating a covering index on the table.

* You can use the SQL Server Profiler Create Trace Wizard with "Identify Scans of Large Tables" trace to determine which tables in your database may need indexes. This trace will show which tables are being scanned by queries instead of using an index.