Understanding data providers,data drivers, Odbc,oledb etc

ODBC - Short for Open DataBase Connectivity, a standard database access method developed by Microsoft Corporation. The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data. ODBC manages this by inserting a middle layer, called a database driver , between an application and the DBMS. The purpose of this layer is to translate the application's data queries into commands that the DBMS understands. For this to work, both the application and the DBMS must be ODBC-compliant -- that is, the application must be capable of issuing ODBC commands and the DBMS must be capable of responding to them. Since version 2.0, the standard supports SAG SQL. OLE DB Over the years, ODBC has become the standard for client/server database access. ODBC provides a standards-based interface that requires SQL processing capabilities and is optimized for a SQL-based approach. However, what happens if you want to access data in a nonrelational data source that doesn't use SQL (e.g., Microsoft Exchange Server, which doesn't store data relationally)? Enter OLE DB. OLE DB builds on ODBC and extends the technology to a component architecture that delivers higher-level data-access interfaces. This architecture provides consistent access to SQL, non-SQL, and unstructured data sources across the enterprise and the Internet. (In fact, for access to SQL-based data, OLE DB still uses ODBC because it's the most optimized architecture for working with SQL.) OLE DB consists of three components: the data consumer (e.g., an application); the data provider, which contains and exposes data; and the service component, which processes and transports data (e.g., query processors, cursor engines). OLE DB is one API that operates against SQL data sources and non-SQL data sources such as mail and directories .Net Data Providers ADO.NET Data Providers are again, a new version of universal data access, that access data sources directly to gain performance advantages. ADO.Net also makes good use of XML standards to more effeciently transmit and cache data. It uses a more TCP-like connectionless metaphor so that all ADO.Net providers use sessionless connections. They get data and don't maintain a session on the server. NET data providers. An essential component of ADO.NET, a .NET data provider implements ADO.NET's interfaces. For example, a .NET data provider would implement the DataReader object so that either your application or the DataSet object could use it.

Interface vs. Abstract classes

Interface vs. Abstract classes Abstract class needs to have at least one "pure virtual method" * In case of Interface all the methods should be "pure virtual" An Abstract class can have all methods as "pure virtual" and still it will not allow multiple inheritance... With Interface multiple inheritance is possible in .Net... Various access modifiers such as abstract, protected, internal, public, virtual, overrides etc are not useful in case of Interface but they are in case of Abstract classes Class implementing Interface has to implement all the methods of the Interface, this is not required in case of Abstract classes As Interface cannot be instantiated, they do not have constructors and destructors like the way Abstract classes can... Interface cannot contain a static method whereas an Abstract class can have... There are few more points which I can recollect but I think that this is enough for a tip... If anyone needs more info do write back to me... :-) * pure virtual method is a method which has just definition but not implementation... **************************************************************************** **************************************************************************** ******************************************* An addition to yesterday's tip... We cannot access static member of a class using object of a class in C#, though this is possible in VB.Net... Thanks to Jacob Cynamon, MS & Kathleen Dollard, MVP for quickly reminding the same... Thanks all for sending a wonderful queries & feedbacks and making my evenings more useful... **************************************************************************** **************************************************************************** ******************************************* PS: Many of us work on weekends, I don't think (current thought!!) that its a good practice doing that, at least if you are being gauged on the basis of your willingness to work on weekends then its surely very bad... I am trying to start a movement to abolish this social evil of working on weekends, so no tips on weekends...:-) BONUS TIP: Spend time with your family this weekend... :-)

How can I run another application or batch file from my Visual C# .NET code?

[Author: Mitesh Mehta]

Suppose you want to run a command line application, open up another Windows program, or even bring up the default web browser or email program... how can you do this from your C# code?

The answer for all of these examples is the same, you can use the classes and methods in System.Diagnostics.Process to accomplish these tasks and more.

Example 1. Running a command line application, without concern for the results:

private void simpleRun_Click(object sender, System.EventArgs e){
 System.Diagnostics.Process.Start(@"C:\listfiles.bat");
}

Example 2. Retrieving the results and waiting until the process stops (running the process synchronously):

private void runSyncAndGetResults_Click(object sender, System.EventArgs e){
 System.Diagnostics.ProcessStartInfo psi =
   new System.Diagnostics.ProcessStartInfo(@"C:\listfiles.bat");
 psi.RedirectStandardOutput = true;
 psi.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
 psi.UseShellExecute = false;
 System.Diagnostics.Process listFiles;
 listFiles = System.Diagnostics.Process.Start(psi);
 System.IO.StreamReader myOutput = listFiles.StandardOutput;
 listFiles.WaitForExit(2000);
 if (listFiles.HasExited)
  {
  string output = myOutput.ReadToEnd();
  this.processResults.Text = output;
 }
}

 Example 3. Displaying a URL using the default browser on the user's machine:

private void launchURL_Click(object sender, System.EventArgs e){
 string targetURL = @Mitesh Mehta ;
 System.Diagnostics.Process.Start(targetURL);
}

In my opinion, you are much better off following the third example for URLs, as opposed to executing IE with the URL as an argument. The code shown for Example 3 will launch the user's default browser, which may or may not be IE; you are more likely to provide the user with the experience they want and you will be taking advantage of the browser that is most likely to have up-to-date connection information.