| Author: Subhashini Janakiraman 11 Feb 2008 | Member Level: Silver | Rating:  Points: 2 |
Indexers are used in .NET which is an extension of the property component in class.Generally they appear in code in vb.net and C#.net.Here is VB code for indexers.
Class:-
public class class1
dim arr() as integer={10,20,30,40,50}
public property indexer1(byval i as integer)as integer
get
return arr(i)
end get
set(byval value as integer)
arr(i)=value
end set
end property
end class
Form:-
public sub button1_click(Byval sender as Object,Byval e as EventArgs)button1.click
dim obj1 as new class1
For i=0 to 4
ListBox1.items.Add(obj1.indexer(i))
Next
obj1.indexer1(3)=60
Msgbox("The indexer value is "& obj.indexer1(3))
end sub
|
| Author: KVGaneshBabu 11 Feb 2008 | Member Level: Diamond | Rating: Points: 2 |
http://www.odetocode.com/Articles/70.aspx
Check this link
|
| Author: Sridhar R 21 Jul 2008 | Member Level: Diamond | Rating: Points: 1 |
Relational databases like SQL Server use indexes to find data quickly when a query is processed. Creating and removing indexes from a database schema will rarely result in changes to an application's code; indexes operate 'behind the scenes' in support of the database engine. However, creating the proper index can drastically increase the performance of an application.
The SQL Server engine uses an index in much the same way a reader uses a book index. For example, one way to find all references to INSERT statements in a SQL book would be to begin on page one and scan each page of the book. We could mark each time we find the word INSERT until we reach the end of the book. This approach is pretty time consuming and laborious. Alternately, we can also use the index in the back of the book to find a page number for each occurrence of the INSERT statements. This approach produces the same results as above, but with tremendous savings in time.
When a SQL Server has no index to use for searching, the result is similar to the reader who looks at every page in a book to find a word: the SQL engine needs to visit every row in a table. In database terminology we call this behavior a table scan, or just scan.
A table scan is not always a problem, and is sometimes unavoidable. However, as a table grows to thousands of rows and then millions of rows and beyond, scans become correspondingly slower and more expensive.
Consider the following query on the Products table of the Northwind database. This query retrieves products in a specific price range.
SELECT ProductID, ProductName, UnitPrice
FROM Products WHERE (UnitPrice > 12.5) AND (UnitPrice < 14)
|