Friday, April 12, 2013
Different Types of SQL Server Functions
Function is a database object in Sql Server. Basically it is a set of sql statements that accepts only input parameters, perform actions and return the result. Function can return only single value or a table. We can’t use function to Insert, Update, Delete records in the database table(s). For more about stored procedure and function refer the article
Types of Function
A.System Defined Function
These functions are defined by Sql Server for different purpose. We have two types of system defined function in Sql Server
1.Scalar Function
Scalar functions operates on a single value and returns a single value. Below is the list of some useful Sql Server Scalar functions.
2.Aggregate Function
Aggregate functions operates on a collection of values and returns a single value. Below is the list of some useful Sql Server Aggregate functions.
B.User Defined Function
These functions are created by user in system database or in user defined database. We three types of user defined functions.
1.Scalar Function
User defined scalar function also returns single value as a result of actions perform by function. We return any datatype value from function.
2.Inline Table-Valued Function
User defined inline table-valued function returns a table variable as a result of actions perform by function. The value of table variable should be derived from a single SELECT statement.
3.Multi-Statement Table-Valued Function
User defined multi-statement table-valued function returns a table variable as a result of actions perform by function. In this a table variable must be explicitly declared and defined whose value can be derived from a multiple sql statements.
Friday, March 20, 2009
The concept of a "Feature" in SharePoint
One of the major concepts in WSS3.0 is the "Feature". The Feature is a container of various defined extensions for SharePoint. It’s a set of XML files which are deployed to web front ends, that can be bundled in site definitions or individually turned on in SharePoint sites. In the next few blog posts, I’ll try to cover some of the more esoteric capabilities of Features, but before I do that, it’s probably helpful to define a Feature, first.
The typical scenario is if you want to deliver a new "Ratings" capability for SharePoint. You want to make it easy for someone to tag any particular item with a rating, and then aggregate those ratings and provide statistics on them. To implement Ratings, you’d need to develop a custom list for storing ratings, and web parts for displaying those ratings. To make this happen in SharePoint, you’d deliver that as a Feature. The Feature would contain a list definition for defining how Ratings are stored, a list instance for defining the common store of Ratings, a web part definition for showing highly rated items, and perhaps a dashboard web page for aggregating different types of rating views together. From the end users perspective, they could "activate" (turn on) your Ratings Feature in their site, and the Ratings list and web parts would be made available to them. (yes, ok, this is just a mythical sample. I'll try to come up with code to illustrate this in a future post.) The key point is that the Feature in SharePoint is a way to bundle all of these extensions together and get them provisioned into a SharePoint site.
Features have a scope, and can be associated with various scopes in SharePoint: web, site, web application, or farm. Depending on the scope, different types of individual elements can be defined in XML. For example, you can associate a List Instance at the Web Scope (every provisioned web will get a list provisioned along with it), but you can’t associate a List Instance at the Farm scope.
Site- or web-scoped Features can also be referenced within a site definition, so that as new sites get created your features will get activated.
Ultimately, though, not every behavior or kind of change you’d want to implement can be expressed in XML. For this reason, you can also define a feature receiver which contains callbacks which will get fired when the Feature is installed or activated.
Features are designed to be a way for developers to express building blocks for SharePoint, and for site admins to pick and choose new functionality they can add to their site. Out of the box, Microsoft Office SharePoint Server and WSS have about 128 features defined, combined. That’s a lot of building blocks :)
Ok, but why is it called a 'Feature"? It’s kind of a bit awkward to talk about the "Feature feature".
Yep, the name "Feature" leads to some occasional contortions when you talk about it.
Why call it a feature? There were a couple of reasons. First, one goal was to make it possible for people to choose a site template, but over time add (or remove) capabilities as people needed them -- the philosophy is that choice of site template shouldn’t be a binding choice to force particular functionality for a site forever. To implement this, we needed to express to site admins which set of capabilities they can turn on. Calling these capabilities "Features" seemed to be more intuitive than calling them something a bit geekier, like "modules" or "components". Because the UI term for these was "Features", it made sense to call the development capability called "Features" too.
Second, the design of features was in part influenced by the way things are defined in Windows Installer. Windows Installer has the concept of "features" and "components". Features are those things you see in some setups where you can pick and choose, in a tree view, which various bits of software to install. For a brief moment the idea for SharePoint was to have features and components too, but to simplify things a little bit we just put features in (not components.)
Well, those are the reasons for the "Feature" name in any case :). The main hope is that with the Features capability we’ve made it easier for developers to create more compartmentalized, reusable bits of functionality for SharePoint.
The typical scenario is if you want to deliver a new "Ratings" capability for SharePoint. You want to make it easy for someone to tag any particular item with a rating, and then aggregate those ratings and provide statistics on them. To implement Ratings, you’d need to develop a custom list for storing ratings, and web parts for displaying those ratings. To make this happen in SharePoint, you’d deliver that as a Feature. The Feature would contain a list definition for defining how Ratings are stored, a list instance for defining the common store of Ratings, a web part definition for showing highly rated items, and perhaps a dashboard web page for aggregating different types of rating views together. From the end users perspective, they could "activate" (turn on) your Ratings Feature in their site, and the Ratings list and web parts would be made available to them. (yes, ok, this is just a mythical sample. I'll try to come up with code to illustrate this in a future post.) The key point is that the Feature in SharePoint is a way to bundle all of these extensions together and get them provisioned into a SharePoint site.
Features have a scope, and can be associated with various scopes in SharePoint: web, site, web application, or farm. Depending on the scope, different types of individual elements can be defined in XML. For example, you can associate a List Instance at the Web Scope (every provisioned web will get a list provisioned along with it), but you can’t associate a List Instance at the Farm scope.
Site- or web-scoped Features can also be referenced within a site definition, so that as new sites get created your features will get activated.
Ultimately, though, not every behavior or kind of change you’d want to implement can be expressed in XML. For this reason, you can also define a feature receiver which contains callbacks which will get fired when the Feature is installed or activated.
Features are designed to be a way for developers to express building blocks for SharePoint, and for site admins to pick and choose new functionality they can add to their site. Out of the box, Microsoft Office SharePoint Server and WSS have about 128 features defined, combined. That’s a lot of building blocks :)
Ok, but why is it called a 'Feature"? It’s kind of a bit awkward to talk about the "Feature feature".
Yep, the name "Feature" leads to some occasional contortions when you talk about it.
Why call it a feature? There were a couple of reasons. First, one goal was to make it possible for people to choose a site template, but over time add (or remove) capabilities as people needed them -- the philosophy is that choice of site template shouldn’t be a binding choice to force particular functionality for a site forever. To implement this, we needed to express to site admins which set of capabilities they can turn on. Calling these capabilities "Features" seemed to be more intuitive than calling them something a bit geekier, like "modules" or "components". Because the UI term for these was "Features", it made sense to call the development capability called "Features" too.
Second, the design of features was in part influenced by the way things are defined in Windows Installer. Windows Installer has the concept of "features" and "components". Features are those things you see in some setups where you can pick and choose, in a tree view, which various bits of software to install. For a brief moment the idea for SharePoint was to have features and components too, but to simplify things a little bit we just put features in (not components.)
Well, those are the reasons for the "Feature" name in any case :). The main hope is that with the Features capability we’ve made it easier for developers to create more compartmentalized, reusable bits of functionality for SharePoint.
Thursday, September 11, 2008
Enabling Output Caching
Add the following code at the top of your .aspx page
'<'%@OutputCache Duration="10" VaryByParam="None" %>
'<'%@OutputCache Duration="10" VaryByParam="None" %>
Turn On Visual Studio 2005 Line Numbering
To view the options dialog box, select Tools, Options from the menus.
Show All Settings Mode:
You will see only Environment, Text Editor and Debugging within the tree structure
Expand the Text Editor branch of the tree. Here you can see a list of all of the languages for which settings may be modified. We will enable line numbering for C# code editing. Expand the C# node of the tree and select the General section to reveal the settings. To enable source code line numbering, tick the appropriate checkbox. Click OK to accept the setting and the line numbers will appear.
Reference:
http://www.blackwasp.co.uk/TurnOnLineNumbering.aspx
Show All Settings Mode:
You will see only Environment, Text Editor and Debugging within the tree structure
Expand the Text Editor branch of the tree. Here you can see a list of all of the languages for which settings may be modified. We will enable line numbering for C# code editing. Expand the C# node of the tree and select the General section to reveal the settings. To enable source code line numbering, tick the appropriate checkbox. Click OK to accept the setting and the line numbers will appear.
Reference:
http://www.blackwasp.co.uk/TurnOnLineNumbering.aspx
Sunday, April 13, 2008
SQL Server
Query for finding the Highest 4 th paid employee from a table
Select * from EMployeeSalary E1 where 4-1=(Select Count(Distinct(e2.ctc)) From EMployeeSalary E2 Where E2.CTC>E1.CTC)
Select * from EMployeeSalary E1 where 4-1=(Select Count(Distinct(e2.ctc)) From EMployeeSalary E2 Where E2.CTC>E1.CTC)
Wednesday, February 13, 2008
Using Synonyms in SQL Server 2005
SQL Server 2005 introduces the concept of a synonym: a single-part name that can replace a two-, three-, or four-part name in many SQL statements.
Using synonyms lets you cut down on typing (always a welcome advance for developers!) and can also provide an abstraction layer to protect you against changes in underlying objects.
Using synonyms lets you cut down on typing (always a welcome advance for developers!) and can also provide an abstraction layer to protect you against changes in underlying objects.
This link provides more details about Synonyms in SQL Server 2005
http://www.developer.com/db/article.php/3613301
SYNONYM is a single-part name that can replace a two, three or four-part name in many SQL statements. Using SYNONYMS in RDBMS cuts down on typing.
SYNONYMs can be created for the following objects:
- Table
- View
- Assembly (CLR) Stored Procedure
- Assembly (CLR) Table-valued Function
- Assembly (CLR) Scalar Function
- Assembly Aggregate (CLR) Aggregate Functions
- Replication-filter-procedure
- Extended Stored Procedure
- SQL Scalar Function
- SQL Table-valued Function
- SQL Inline-table-valued Function
- SQL Stored Procedure
More details available at
http://www.databasejournal.com/features/mssql/article.php/3635426
Subscribe to:
Posts (Atom)