In debug compilation, assert takes in a Boolean condition 
as a parameter, and shows the error dialog if the condition 
is false. The program proceeds without any interruption if 
the condition is true.

Side-by-side execution is the ability to run multiple 
versions of an application or component on the same 
computer.

You can have multiple versions of the common language 
runtime, and multiple versions of applications and 
components that use a version of the runtime, on the same 
computer at the same time.

Since versioning is only applied to shared assemblies, and 
not to private assemblies, two application one using 
private assembly and one using shared assembly cannot be 
stated as side-by-side executables.

We can dynamically reference an assembly by providing only 
partial information, such as specifying only the assembly 
name. When you specify a partial assembly reference, the 
runtime looks for the assembly only in the application 
directory.

We can make partial references to an assembly in your code 
one of the following ways:

1) Use a method such as System.Reflection.Assembly.Load and 
specify only a partial reference. The runtime checks for 
the assembly in the application directory.

method and specify only a partial reference. The runtime 
checks for the assembly in the application directory and in 
the global assembly cache.

A full assembly reference includes the assembly's text 
name, version, culture, and public key token assembly has a 
A full assembly reference is required if you reference any 
assembly that is part of the common language runtime or any 
assembly located in the global assembly cache. You can also 
dynamically reference an assembly by providing only partial 
information, such as specifying only the assembly name. 
When you specify a partial assembly reference, the runtime 
looks for the assembly only in the application directory.

All .NET compilers produce metadata about the types defined 
in the modules they produce. This metadata is packaged 
along with the module (modules in turn are packaged 
together in assemblies), and can be accessed by a mechanism 
called reflection.

The System.Reflection namespace contains classes that can 
be used to interrogate the types for a module/assembly. 

Using reflection to access .NET metadata is very similar to 
using ITypeLib/ITypeInfo to access type library data in 
COM, and it is used for similar purposes - e.g. determining 
data type sizes for marshaling data across 
context/process/machine boundaries.

Reflection can also be used to dynamically invoke methods ( 
System.Type.InvokeMember ) ,  or even create types 
dynamically at run-timeystem.Reflection.Emit.TypeBuilder). 

reflection is a collection of metadata and combination of
manifest.it can also be used to dynamically invoked method.

The runtime supports Windows XP, Windows 2000, NT4 SP6a and 
Windows ME/98. Windows 95 is not supported. Some parts of 
the framework do not work on all platforms .

for example, ASP.NET is only supported on Windows XP and 
Windows 2000. Windows 98/ME cannot be used for development.
IIS is not supported on Windows XP Home Edition, and so 
cannot be used to host ASP.NET. However, the ASP.NET Web 
Matrix 
web server does run on XP Home.
The Mono project is attempting to implement the .NET 
framework on Linux.

use the Fill method of the DataAdapter control and pass the 
dataset object as an argument to load the generated data.

use the Fill method of the DataAdapter control and pass the 
dataset object as an argument to load the generated data.

DataAdapters Fill() method.

ADO.NET provides DataRelation object to set relation 
between two columns.It helps to enforce the following  
constraints,a unique constraint, which guarantees that a 
column in the table  contains no duplicates and a foreign-
key constraint,which can be used to maintain referential  
integrity.

A unique constraint is implemented either by simply setting 
the Unique property of a data  column to true, or by adding 
an instance of the UniqueConstraint class to the 
DataRelation object's ParentKeyConstraint.

As part of the foreign-key constraint, you can specify 
referential integrity  rules that are applied at three 
points,when a parent record is updated,when a parent record 
is deleted and when a change is accepted or rejected.

the only option is foreign key

DataSet d = new DataSet();
        DataColumn parentDC = new
DataColumn(d.Tables["parentTable"].Columns["id"]);
        DataColumn childDC = new
DataColumn(d.Tables["ChildTable"].Columns["id"]);
        DataRelation ds = new DataRelation("relation name",
parentDC, childDC);
       d.Relations.Add(ds);

One of the key features of the ADO.NET DataSet is that it 
can be a self-contained and disconnected data store. It can 
contain the schema and data from several rowsets in 
DataTable objects as well as information about how to 
relate the DataTable objects-all in memory.

The DataSet neither knows nor cares where the data came 
from, nor does it need a link to an underlying data source. 
Because it is data source agnostic you can pass the DataSet 
around networks or even serialize it to XML and pass it 
across the Internet without losing any of its features. 
However, in a disconnected model, concurrency obviously 
becomes a much bigger problem than it is in a connected 
model.

The answer given above is not answer of the question. 
Please provide the correct answers.

concuracy is handled by the help of timestamp..
or checking the original data onece again before edit or 
delete.

1)consuraancy can be done with the help of dataset   
methods   like acceptchanges().
2)using timestamp

Pessimistic locking, last-win-approach and optimistic 
locking

ADO.NET and Visual Studio use optimistic concurrency,
because the data architecture is based on disconnected data.
Therefore, you need to add business logic to resolve issues
with optimistic concurrency.
(1.optimistic 2.pessimistic  3.Last in wins)
If you choose to use optimistic concurrency, there are two
general ways to determine if changes have occurred: the
version approach (true version numbers or date-time stamps)
and the saving-all-values approach.
The Version Number Approach
In the version number approach, the record to be updated
must have a column that contains a date-time stamp or
version number. The date-time stamp or a version number is
saved on the client when the record is read. This value is
then made part of the update.
One way to handle concurrency is to update only if value in
the WHERE clause matches the value on the record. The SQL
representation of this approach is:
 Copy Code
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2
WHERE DateTimeStamp = @origDateTimeStamp
Alternatively, the comparison can be made using the version
number:
 Copy Code
UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2
WHERE RowVersion = @origRowVersionValue
If the date-time stamps or version numbers match, the record
in the data store has not changed and can be safely updated
with the new values from the dataset. An error is returned
if they don't match. You can write code to implement this
form of concurrency checking in Visual Studio. You will also
have to write code to respond to any update conflicts. To
keep the date-time stamp or version number accurate, you
need to set up a trigger on the table to update it when a
change to a row occurs.
The Saving-All-Values Approach
An alternative to using a date-time stamp or version number
is to get copies of all the fields when the record is read.
The DataSet object in ADO.NET maintains two versions of each
modified record: an original version (that was originally
read from the data source) and a modified version,
representing the user updates. When attempting to write the
record back to the data source, the original values in the
data row are compared against the record in the data source.
If they match, it means that the database record has not
changed since it was read. In that case, the changed values
from the dataset are successfully written to the database.
Each data adapter command has a parameters collection for
each of its four commands (DELETE, INSERT, SELECT, and
UPDATE). Each command has parameters for both the original
values, as well as the current (or modified) values.
Note: use time stamps to avoid concurrency violations

ADO.Net is the data access model for .Net ?based 
applications. It can be used to access relational database 
systems such as SQL SERVER 2000, Oracle, and many other 
data sources for which there is an OLD DB or ODBC provider.

To a certain extent, ADO.NET represents the latest 
evolution of ADO technology. However, ADO.NET introduces 
some major changes and innovations that are aimed at the 
loosely coupled and inherently disconnected ? nature of web 
applications.


A .Net Framework data provider is used to connecting to a 
database, executing commands, and retrieving results. Those 
results are either processed directly, or placed in an 
ADO.NET DataSet in order to be exposed to the user in an ad-
hoc manner, combined with data from multiple sources, or 
remoted between tiers. The .NET Framework data provider is 
designed to be lightweight, creating a minimal layer 
between the data source and your code, increasing 
performance without sacrificing functionality.


Following are the 4 core objects of .Net Framework Data 
provider:

Connection: Establishes a connection to a specific data 
source .

Command:  Executes a command against a data source. Exposes 
Parameters and can execute within the scope of a 
Transaction from a Connection. 

DataReader: Reads a forward-only, read-only stream of data 
from a data source. 

DataAdapter: Populates a DataSet and resolves updates with 
the data source.

The .NET Framework includes the .NET Framework Data 
Provider for SQL Server (for Microsoft SQL Server version 
7.0 or later), the .NET Framework Data Provider for OLE DB, 
and the .NET Framework Data Provider for ODBC.

The .NET Framework Data Provider for SQL Server:  The .NET 
Framework Data Provider for SQL Server uses its own 
protocol to communicate with SQL Server. It is lightweight 
and performs well because it is optimized to access a SQL 
Server directly without adding an OLE DB or Open Database 
Connectivity (ODBC) layer. 

The following illustration contrasts the .NET Framework 
Data Provider for SQL Server with the .NET Framework Data 
Provider for OLE DB. The .NET Framework Data Provider for 
OLE DB communicates to an OLE DB data source through both 
the OLE DB Service component, which provides connection 
pooling and transaction services, and the OLE DB Provider 
for the data source .


The .NET Framework Data Provider for OLE DB: The .NET 
Framework Data Provider for OLE DB uses native OLE DB 
through COM interoperability to enable data access. 
The .NET Framework Data Provider for OLE DB supports both 
local and distributed transactions. 

For distributed transactions, the .NET Framework Data 
Provider for OLE DB, by default, automatically enlists in a 
transaction and obtains transaction details from Windows 
2000 Component Services.


The .NET Framework Data Provider for ODBC: The .NET 
Framework Data Provider for ODBC uses native ODBC Driver 
Manager (DM) through COM interoperability to enable data 
access. The ODBC data provider supports both local and 
distributed transactions. For distributed transactions, the 
ODBC data provider, by default, automatically enlists in a 
transaction and obtains transaction details from Windows 
2000 Component Services.

The .NET Framework Data Provider for Oracle: The .NET 
Framework Data Provider for Oracle enables data access to 
Oracle data sources through Oracle client connectivity 
software. The data provider supports Oracle client software 
version 8.1.7 and later. The data provider supports both 
local and distributed transactions (the data provider 
automatically enlists in existing distributed transactions, 
but does not currently support the 
EnlistDistributedTransaction method).


The .NET Framework Data Provider for Oracle requires that 
Oracle client software (version 8.1.7 or later) be 
installed on the system before you can use it to connect to 
an Oracle data source.


.NET Framework Data Provider for Oracle classes are located 
in the System.Data.OracleClient namespace and are contained 
in the System.Data.OracleClient.dll assembly. You will need 
to reference both the System.Data.dll and the 
System.Data.OracleClient.dll when compiling an application 
that uses the data provider.

Choosing a .NET Framework Data Provider
.NET Framework Data Provider for SQL Server: Recommended 
for middle-tier applications using Microsoft SQL Server 7.0 
or later. Recommended for single-tier applications using 
Microsoft Data Engine (MSDE) or Microsoft SQL Server 7.0 or 
later.


Recommended over use of the OLE DB Provider for SQL Server 
(SQLOLEDB) with the .NET Framework Data Provider for OLE 
DB. For Microsoft SQL Server version 6.5 and earlier, you 
must use the OLE DB Provider for SQL Server with the .NET 
Framework Data Provider for OLE DB.


.NET Framework Data Provider for OLE DB: Recommended for 
middle-tier applications using Microsoft SQL Server 6.5 or 
earlier, or any OLE DB provider. For Microsoft SQL Server 
7.0 or later, the .NET Framework Data Provider for SQL 
Server is recommended. Recommended for single-tier 
applications using Microsoft Access databases. Use of a 
Microsoft Access database for a middle-tier application is 
not recommended.


.NET Framework Data Provider for ODBC: Recommended for 
middle-tier applications using ODBC data sources. 
Recommended for single-tier applications using ODBC data 
sources.


.NET Framework Data Provider for Oracle: Recommended for 
middle-tier applications using Oracle data sources. 
Recommended for single-tier applications using Oracle data 
sources. Supports Oracle client software version 8.1.7 and 
later. The .NET Framework Data Provider for Oracle classes 
are located in the System.Data.OracleClient namespace and 
are contained in the System.Data.OracleClient.dll assembly. 
You need to reference both the System.Data.dll and the 
System.Data.OracleClient.dll when compiling an application 
that uses the data provider.

ADO.NET provides 2 types of architecture. 
1. Connection Oriented 
2. Connectionless

Connection Oriented architecture is achieved by the use of 
Connection, Command and DataReader. Connection management 
should done by the user. This architecture is used for 
viewing data for continuous monitoring of data.

Connectionless architecture is achieved by the use of 
Connection, Command and DataAdapter. The data is retrieved 
from the database and stored in the dataset(local 
representation of a part or full of actual database). The 
connection management is handled by the DataAdapter. The 
connection is created when the query or DML operation is 
run against the database and cut immediately after the 
operation is over. This architecture is mainly used for 
doing Modifications in the data.

The SqlDataAdapter has SelectCommand, InsertCommand, 
DeleteCommand and UpdateCommand.

The term ACID conveys the role transactions play in mission-
critical applications. Coined by transaction processing 
pioneers, ACID stands for atomicity, consistency, 
isolation, and durability.

These properties ensure predictable behavior, reinforcing 
the role of transactions as all-or-none propositions 
designed to reduce the management load when there are many 
variables.

Atomicity

A transaction is a unit of work in which a series of 
operations occur between the BEGIN TRANSACTION and END 
TRANSACTION statements of an application. A transaction 
executes exactly once and is atomic ? all the work is done 
or none of it is.

Operations associated with a transaction usually share a 
common intent and are interdependent. By performing only a 
subset of these operations, the system could compromise the 
overall intent of the transaction. Atomicity eliminates the 
chance of processing a subset of operations.

Consistency

A transaction is a unit of integrity because it preserves 
the consistency of data, transforming one consistent state 
of data into another consistent state of data.
Consistency requires that data bound by a transaction be 
semantically preserved. Some of the responsibility for 
maintaining consistency falls to the application developer 
who must make sure that all known integrity constraints are 
enforced by the application. For example, in developing an 
application that transfers money, you should avoid 
arbitrarily moving decimal points during the transfer.

Isolation


A transaction is a unit of isolation ? allowing concurrent 
transactions to behave as though each were the only 
transaction running in the system.
Isolation requires that each transaction appear to be the 
only transaction manipulating the data store, even though 
other transactions may be running at the same time. A 
transaction should never see the intermediate stages of 
another transaction.
Transactions attain the highest level of isolation when 
they are serializable. At this level, the results obtained 
from a set of concurrent transactions are identical to the 
results obtained by running each transaction serially. 
Because a high degree of isolation can limit the number of 
concurrent transactions, some applications reduce the 
isolation level in exchange for better throughput.


Durability

A transaction is also a unit of recovery. If a transaction 
succeeds, the system guarantees that its updates will 
persist, even if the computer crashes immediately after the 
commit. Specialized logging allows the system's restart 
procedure to complete unfinished operations, making the 
transaction durable.

There are four types of Rowversions.

Current:

The current values for the row. This row version does not 
exist for rows with a RowState of Deleted.

Default :

The row the default version for the current DataRowState. 
For a DataRowState value of Added, Modified or Current, the 
default version is Current. For a DataRowState of Deleted, 
the version is Original. For a DataRowState value of 
Detached, the version is Proposed.

Original:
The row contains its original values.

Proposed:
The proposed values for the row. This row version exists 
during an edit operation on a row, or for a row that is not 
part of a DataRowCollection.

have a look at this link

http://msdn2.microsoft.com/en-us/library/ww3k31w0.aspx

Serialized  : Data read by a current transaction cannot be 
changed by another transaction until the current 
transaction finishes. No new data can be inserted that 
would affect the current transaction. This is the safest 
isolation level and is the default. 

 
Repeatable : Read   Data read by a current transaction 
cannot be changed by another transaction until the current 
transaction finishes. Any type of new data can be inserted 
during a transaction.  


Read Committed  : A transaction cannot read data that is 
being modified by another transaction that has not 
committed. This is the default isolation level in 
Microsoft? SQL Server. 
 
Read Uncommitted :  A transaction can read any data, even 
if it is being modified by another transaction. This is the 
least safe isolation level but allows the highest 
concurrency.  


Any   Any isolation level is supported. This setting is 
most commonly used by downstream components to avoid 
conflicts. This setting is useful because any downstream 
component must be configured with an isolation level that 
is equal to or less than the isolation level of its 
immediate upstream component. 

Therefore, a downstream component that has its isolation 
level configured as Any always uses the same isolation 
level that its immediate upstream component uses. If the 
root object in a transaction has its isolation level 
configured to Any, its isolation level becomes Serialized.

have a look at this link


http://msdn2.microsoft.com/en-us/library/aa213034.aspx

No.

NO u cannot edit in the repeater control.only u can display
the data in the repeating sequence thats it.but in datagrid
and datalist u can do edit /update options

100% after all controls are for us we can edit data for ex 
look at following code.
asp:Repeater ID="Repeater1" runat="server" 
DataSourceID="SqlDataSource1">
<Item Template>
<asp:Label id="Id" Text='<%# DataBinder.Eval
(Container.DataItem, "name") %>' runat="server" />
<br />
<br />

<asp:Label id="Label1" Text='<%# DataBinder.Eval
(Container.DataItem, "id") %>' runat="server" />
<br />

</ItemTemplate>
</asp:Repeater> if we are making this then w e can also 
edit data.
Important links- 
http://www.asp101.com/articles/john/repeater/default.asp
                           http://msdn2.microsoft.com/en-
us/library/ms178369(VS.80).aspx
                         
http://www.code101.com/Code101/DisplayArticle.aspx?cid=1
                         
http://authors.aspalliance.com/aspxtreme/aspnet/syntax/repea
terwebcontrol.aspx
                         http://www.techinterviews.com/?
p=249

No

NO u cannot edit in the repeater control.only u can display
the data in the repeating sequence thats it

No

No you cannot edit

A DiffGram is an XML format that is used to identify 
current and original versions of data elements. The DataSet 
uses the DiffGram format to load and persist its contents, 
and to serialize its contents for transport across a 
network connection. When a DataSet is written as a 
DiffGram, it populates the DiffGram with all the necessary 
information to accurately recreate the contents, though not 
the schema, of the DataSet, including column values from 
both the Original and Current row versions, row error 
information, and row order.
When sending and retrieving a DataSet from an XML Web 
service, the DiffGram format is implicitly used. 
Additionally, when loading the contents of a DataSet from 
XML using the ReadXml method, or when writing the contents 
of a DataSet in XML using the WriteXml method, you can 
select that the contents be read or written as a DiffGram. 
The DiffGram format is divided into three sections: the 
current data, the original (or "before") data, and an 
errors section, as shown in the following example.
<?xml version="1.0"?>
<diffgr:diffgram 
         xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"
         xmlns:diffgr="urn:schemas-microsoft-com:xml-
diffgram-v1"
         xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <DataInstance>
   </DataInstance>
  <diffgr:before>
  </diffgr:before>
  <diffgr:errors>
  </diffgr:errors>
</diffgr:diffgram>
The DiffGram format consists of the following blocks of 
data: 
<DataInstance> 
The name of this element, DataInstance, is used for 
explanation purposes in this documentation. A DataInstance 
element represents a DataSet or a row of a DataTable. 
Instead of DataInstance, the element would contain the name 
of the DataSet or DataTable. This block of the DiffGram 
format contains the current data, whether it has been 
modified or not. An element, or row, that has been modified 
is identified with the diffgr:hasChanges annotation. 
<diffgr:before> 
This block of the DiffGram format contains the original 
version of a row. Elements in this block are matched to 
elements in the DataInstance block using the diffgr:id 
annotation. 
<diffgr:errors> 
This block of the DiffGram format contains error 
information for a particular row in the DataInstance block. 
Elements in this block are matched to elements in the 
DataInstance block using the diffgr:id annotation.