public DataSet readCsv()
{
try
{
string strPath = @"Path of the file";
string ConnectionString =
string.Format(@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source={0};
Extended Properties=""text;HDR=Yes;FMT=Delimited"";"
, strPath);
string CommandText = string.Format(@"SELECT * FROM Nameofthefile.csv", ConnectionString);
DataSet CSVDataSet = new DataSet();
OleDbConnection CSVConnection = new OleDbConnection(ConnectionString);
OleDbDataAdapter CSVAdapter = new OleDbDataAdapter(CommandText, CSVConnection);
CSVConnection.Open();
CSVAdapter.Fill(CSVDataSet, "FileName.csv");
CSVConnection.Close();
GVcsv.DataSource = CSVDataSet;
GVcsv.DataBind();
return CSVDataSet;
}
catch (Exception ex)
{
lblerror.Text = ex.Message;
throw ex;
}
}
Reading CSV and Bind to GridView
Integer validation
here field is textbox where user enters value
function val3(field)
{
var valid = "0123456789"
var ok = "yes";
var temp;
for (var i=0; i{
temp = "" + field.value.substring(i, i+1);
if (valid.indexOf(temp) == "-1")
ok = "no";
}
if (ok == "no")
{
alert("Invalid entry! Only numbers are accepted!");
}
}
function val3(field)
{
var valid = "0123456789"
var ok = "yes";
var temp;
for (var i=0; i
temp = "" + field.value.substring(i, i+1);
if (valid.indexOf(temp) == "-1")
ok = "no";
}
if (ok == "no")
{
alert("Invalid entry! Only numbers are accepted!");
}
}
Email Validation
Here str is textbox where user enters email id
<script language="javascript">
function echeck(str)
{
var at="@"
var dot="."
var lat=str.indexOf(at)
var lstr=str.length
var ldot=str.indexOf(dot)
if (str.indexOf(at)==-1)
{
alert("Invalid E-mail ID")
return false
}
if (str.indexOf(at)==-1 || str.indexOf(at)==0 || str.indexOf(at)==lstr)
{
alert("Invalid E-mail ID")
return false
}
if (str.indexOf(dot)==-1 || str.indexOf(dot)==0 || str.indexOf(dot)==(lstr-1))
{
alert("Invalid E-mail ID")
return false
}
if (str.indexOf(at,(lat+1))!=-1)
{
alert("Invalid E-mail ID")
return false
}
if (str.substring(lat-1,lat)==dot || str.substring(lat+1,lat+2)==dot)
{
alert("Invalid E-mail ID")
return false
}
if (str.indexOf(dot,(lat+2))==-1)
{
alert("Invalid E-mail ID")
return false
}
if (str.indexOf(" ")!=-1)
{
alert("Invalid E-mail ID")
return false
}
}
</script>
xml-11
copy1)Explain what a DiffGram is, and a good use for one?
Answer : A DiffGram is an XML format that is used to identify current and original versions of data elements. When sending and retrieving a DataSet from an XML Web service, the DiffGram format is implicitly used.
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.
DiffGram Format
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.
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”>
The DiffGram format consists of the following blocks of data:
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.
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.
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.
Answer : A DiffGram is an XML format that is used to identify current and original versions of data elements. When sending and retrieving a DataSet from an XML Web service, the DiffGram format is implicitly used.
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.
DiffGram Format
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.
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”>
The DiffGram format consists of the following blocks of data:
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.
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.
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.
Tracing Overview-3
Tracing Overview
To enable tracing for a page, include the following directive at the top of the page code:
Trace statements can also be organized by category, using the TraceMode attribute of the Page directive. If no TraceMode attribute is defined, the default value is SortByTime.
• Page-level Tracing: At the page level, developers can use the TraceContext instrinsic to write custom debugging statements that appear at the end of the client output delivered to the requesting browser. ASP.NET also inserts some helpful statements regarding the start/end of lifecycle methods, like Init, Render, and PreRender, in addition to the inputs and outputs to a page, such as form and QueryString variables or headers, and important statistics about the page's execution (control hierarchy, session state, and application state). Because tracing can be explicitly enabled or disabled for a page, these statements can be left in the production code for a page with no impact to the page's performance. Each statement can be associated with a user-defined category for organizational purposes, and timing information is automatically collected by the ASP.NET runtime. The resulting output can be ordered by either time or category.
• Application-level Tracing: Application-level tracing provides a view of several requests to an application's pages at once. Like page-level tracing, it also displays inputs and outputs to a page, such as form and QueryString variables or headers, as well as some important statistics (control hierarchy, session state, and application state). Application-level tracing is enabled through the ASP.NET configuration system, and accessed as a special mapped URL into that application (Trace.axd). When application tracing is enabled, page-level tracing is automatically enabled for all pages in that application (provided there is no page-level directive to explicitly disable trace).
Application-level Trace Logging
The attributes supported in the trace configuration section are listed in the table below:
Value ...............................................................................Description
enabled ...........................................................................Set to true false, indicates whether Tracing is enabled for the application (default is false)
pageOutput .....................................................................Set to true false, indicates whether trace information should be rendered at the end of each page - or only accessible via the trace.axd utility (default is false)
requestLimit ..................................................................Number of trace requests to store on the server (default is 10)
traceMode .....................................................................Set to SortByTime SortByCategory, indicates the display order for Trace messages (default is SortByTime)
localOnly .......................................................................Set to true false, indicates whether Tracing is enabled for localhost users or for all users (default is true)
To enable tracing for a page, include the following directive at the top of the page code:
Trace statements can also be organized by category, using the TraceMode attribute of the Page directive. If no TraceMode attribute is defined, the default value is SortByTime.
• Page-level Tracing: At the page level, developers can use the TraceContext instrinsic to write custom debugging statements that appear at the end of the client output delivered to the requesting browser. ASP.NET also inserts some helpful statements regarding the start/end of lifecycle methods, like Init, Render, and PreRender, in addition to the inputs and outputs to a page, such as form and QueryString variables or headers, and important statistics about the page's execution (control hierarchy, session state, and application state). Because tracing can be explicitly enabled or disabled for a page, these statements can be left in the production code for a page with no impact to the page's performance. Each statement can be associated with a user-defined category for organizational purposes, and timing information is automatically collected by the ASP.NET runtime. The resulting output can be ordered by either time or category.
• Application-level Tracing: Application-level tracing provides a view of several requests to an application's pages at once. Like page-level tracing, it also displays inputs and outputs to a page, such as form and QueryString variables or headers, as well as some important statistics (control hierarchy, session state, and application state). Application-level tracing is enabled through the ASP.NET configuration system, and accessed as a special mapped URL into that application (Trace.axd). When application tracing is enabled, page-level tracing is automatically enabled for all pages in that application (provided there is no page-level directive to explicitly disable trace).
Application-level Trace Logging
The attributes supported in the trace configuration section are listed in the table below:
Value ...............................................................................Description
enabled ...........................................................................Set to true false, indicates whether Tracing is enabled for the application (default is false)
pageOutput .....................................................................Set to true false, indicates whether trace information should be rendered at the end of each page - or only accessible via the trace.axd utility (default is false)
requestLimit ..................................................................Number of trace requests to store on the server (default is 10)
traceMode .....................................................................Set to SortByTime SortByCategory, indicates the display order for Trace messages (default is SortByTime)
localOnly .......................................................................Set to true false, indicates whether Tracing is enabled for localhost users or for all users (default is true)
Configuration File Format
Configuration File Format
ASP.NET configuration files are XML-based text files--each named web.config--that can appear in any directory on an ASP.NET Web application server. Each web.config file applies configuration settings to the directory it is located in and to all virtual child directories beneath it. Settings in child directories can optionally override or modify settings specified in parent directories. The root configuration file--WinNT\Microsoft.NET\Framework\\config\machine.config--provides default configuration settings for the entire machine. ASP.NET configures IIS to prevent direct browser access to web.config files to ensure that their values cannot become public (attempts to access them will cause ASP.NET to return 403: Access Forbidden).
If a web.config file is present at the root directory for a site, for example "Inetpub\wwwroot", its configuration settings will apply to every application in that site. Note that the presence of a web.config file within a given directory or application root is completely optional. If a web.config file is not present, all configuration settings for the directory are automatically inherited from the parent directory.
Configuration Section Handlers and Sections
A web.config file is an XML-based text file that can contain standard XML document elements, including well-formed tags, comments, text, cdata, and so on. The file may be ANSI, UTF-8, or Unicode; the system automatically detects the encoding. The root element of a web.config file is always a tag. ASP.NET and end-user settings are then encapsulated within the tag, as follows:
The tag typically contains three different types of elements:
1) Configuration section handler declarations
2) Configuration section groups and
3) Configuration section settings
ASP.NET configuration files are XML-based text files--each named web.config--that can appear in any directory on an ASP.NET Web application server. Each web.config file applies configuration settings to the directory it is located in and to all virtual child directories beneath it. Settings in child directories can optionally override or modify settings specified in parent directories. The root configuration file--WinNT\Microsoft.NET\Framework\
If a web.config file is present at the root directory for a site, for example "Inetpub\wwwroot", its configuration settings will apply to every application in that site. Note that the presence of a web.config file within a given directory or application root is completely optional. If a web.config file is not present, all configuration settings for the directory are automatically inherited from the parent directory.
Configuration Section Handlers and Sections
A web.config file is an XML-based text file that can contain standard XML document elements, including well-formed tags, comments, text, cdata, and so on. The file may be ANSI, UTF-8, or Unicode; the system automatically detects the encoding. The root element of a web.config file is always a
The
1) Configuration section handler declarations
2) Configuration section groups and
3) Configuration section settings
Authentication
1. ASP.NET Authentication Providers and IIS Security
ASP.NET implements authentication using authentication providers, which are code modules that verify credentials and implement other security functionality such as cookie generation. ASP.NET supports the following three authentication providers:
Forms Authentication: Using this provider causes unauthenticated requests to be redirected to a specified HTML form using client side redirection. The user can then supply logon credentials, and post the form back to the server. If the application authenticates the request (using application-specific logic), ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary.
Passport Authentication: This is a centralized authentication service provided by Microsoft that offers a single logon facility and membership services for participating sites. ASP.NET, in conjunction with the Microsoft® Passport software development kit (SDK), provides similar functionality as Forms Authentication to Passport users.
Windows Authentication: This provider utilizes the authentication capabilities of IIS. After IIS completes its authentication, ASP.NET uses the authenticated identity's token to authorize access.
To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows:
// web.config file
ASP.NET implements authentication using authentication providers, which are code modules that verify credentials and implement other security functionality such as cookie generation. ASP.NET supports the following three authentication providers:
Forms Authentication: Using this provider causes unauthenticated requests to be redirected to a specified HTML form using client side redirection. The user can then supply logon credentials, and post the form back to the server. If the application authenticates the request (using application-specific logic), ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary.
Passport Authentication: This is a centralized authentication service provided by Microsoft that offers a single logon facility and membership services for participating sites. ASP.NET, in conjunction with the Microsoft® Passport software development kit (SDK), provides similar functionality as Forms Authentication to Passport users.
Windows Authentication: This provider utilizes the authentication capabilities of IIS. After IIS completes its authentication, ASP.NET uses the authenticated identity's token to authorize access.
To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows:
// web.config file
Subscribe to:
Posts (Atom)