We Keep Coding

Difference between Native SQL and Entity SQL

I have gone through an article of using EntityConnection, EntityCommands for executing Entity sql queries. But I was unable to understand that Why are we using Entity sql? Why not directly using the Classes and objects for processing CRUD operations on database?
Or If we want to execute sql queries then why we are using Entity Sql , why not directly Ado.net ?
Is there any performance difference or something else?
I have already gone through the page http://msdn.microsoft.com/en-us/library/bb738573.aspx. But I want answer in a more simpler way. Can you please answer me?
Thanks

Why not directly using the Classes and objects for processing CRUD operations on database?
That is (should be) the way for almost all operations. But sometimes there is a need for accessing the db more directly and precisely.
If we want to execute sql queries then why we are using Entity Sql , why not directly Ado.net ?
E-SQL will still let you work with entities (instead of Rows). This is much easier and more powerful, consider inheritance for example.
E-SQL is also supposed to be independent of the actual database, ie the same for Oracle etc. I have no experience with this yet.
Is there any performance difference or something else?
It can be used to improve performance, yes. But not automatically.

The main difference
SQL is database dependent query language working on storage (relational) objects - tables / rows
ESQL is database independent query language working on conceptual (EDMX) objects - entities
ESQL was created prior to LINQ. In some scenarios ESQL offers more functionality than LINQ.

How to connect to a MySQL database inside the .NET framework?

I'm opening a discussion here on a subject I couldn't find any answer good enough to be called a final answer: MySQL and .NET.
While I know there is a lot of ways to make this connection, I'm trying to find a list of pros and cons of each approach.
I've been using ADO.NET with the MySQL NETconnector since the beggining of my project, and everything was ok when the database was new and didn't have many records. But now I'm facing a situation where the number of records grows exponentially, and I found other way of querying against the database, which is the ODBC connector. Using the ADO.NET + NETConnector solution I had my O/RM and didn't have to write my queries, while ODBC makes my code look awful now (since I didn't switch completely to ODBC, I have Linq queries and plain SQL queries inside my code).
Is there any solution (free or not) where I can have both an O/RM without the need of writing SQL queries myself and the speed of ODBC?

What you should be doing is using the MySQL ADO.NET Connector and storing your queries in the database in the form of stored procedures. Version 6.0 of the MySQL connector also supports The Entity Framework. If you are interested in using the Entity Framework, check out this link which describes how to set that up.

NHibernate
Update to Comments
NHibernate Proxy Generators
It is a byte code generator for your object model that allows NHibernate to perform lazy loading and other operations. The link provided explains the benefits.
Castle and LinFu are two different implementations of those Proxy Generators.
While NHibernate does not have coincide documentation all the information on how to use it, is on the internet. This could be a barrier to usability for some people though. I understand more about NHibernate because of my past experience with Hibernate.

ADO.NET or Linq to SQL?

I am building a forum, and it has got 4 tables: Users, Threads, Comments, Topics.
I established the connection and the pages.. I started using the ADO.net way to insert data and select data..but then I found that to make more complex manipulations i need to know SQL. So I was looking for another way, and I found that I can open Visual Studio 2010, add Linq to SQL file that produced object relational designer. I read about how to write code, and I saw that I simply need to use a using statement with DataContext object with a simple code to update, add, delete rows in the tables.
I wanted to know, what are the advantages of using one way of querying over another?

ADO.NET gives you low level control over your queries. If query speed is going to be of importance, this is where you want to be. If you speed is not very important, but rapid development and an Object Relational Model is, LINQ to SQL is a safe bet.
I would recommend Linq to SQL over ADO.NET though.
Development is rapid and thinking in an ORM way is natural.
If your queries are too slow, using the .ExecuteQuery method will allow you to pass in a sql statement that you have optimized as if you were doing it in the ADO.NET way. I have had much success with Linq to Sql.
Also I would look at Entity Framework. It gives you more control over your objects and how they are implemented, used and handled than Linq.

LINQ to SQL is part of the ADO.NET family of technologies. It is based on services provided by the ADO.NET provider model. You can therefore mix LINQ to SQL code with existing ADO.NET applications and migrate current ADO.NET solutions to LINQ to SQL. The following illustration provides a high-level view of the relationship.
Refer to the following:
ADO.NET and LINQ to SQL
Advantages & Disadvantages of LINQ
Performance of LINQ to SQL over Normal Stored procedure
LINQ-to-SQL and Stored Procedures

LINQ to SQL is great in that it generates alot of the plumbing code for you. But it is basically the same as using straight up ADO.NET/SQL. To do more complex data manipulation in LINQ to SQL you have to know how write complex joins in LINQ just as you would in SQL.
Look into Entity Framework - it might give you a higher level of abstraction that you are looking for.

The two are on different abstraction levels. ADO.NET is the lowest level of data access in .NET. Anything else will build upon it.
Every abstraction should give you power to express higher-level concepts at the cost of lower level concepts.
If I sound like a philosopher it's because it's Friday.

In addition to Entity Framework, you can take a look at NHibernate (another .net Object Relational Mapper). It's been around longer than EF so it's a bit more mature, but it isn't developed by Microsoft if that matters to you.

Where to store application data

I'm building a C#/WPF job search tracking application to keep track of resumes submitted, interviews, followups, etc and am not sure of the best way to store the data. Where/how would YOU store the data? My first thought was XML to keep it simple, but it seems like I should "model" my data since there will be lots of related bits of information. Would SQLite be a better choice? Other recommendations?

Since I assume you want to query and update that data I would even suggest an ORM like Entity Framework - it's easy to get started and the basic stuff like querying and updating will be very straightforward if you have worked with LINQ before - saves you the hassle of writing your own SQL queries. This also will allow you to easily extend your model later on should you decide to do so.
Edit:
There are self-contained light-weight alternatives that would still allow you to use LINQ:
SQL Server Compact:
Microsoft SQL Server Compact is a free
SQL Server embedded database ideal for
building standalone and occasionally
connected applications for mobile
devices, desktops, and Web clients.
Here' an article that describes how to get LINQ to SQL to work on it. Apparently you can also use LINQ to Entities on it but there's quirks (such as design-time support) that you'll have to work around.
SQLLite:
SQLite is a software library that
implements a self-contained,
serverless, zero-configuration,
transactional SQL database engine.
SQLite is the most widely deployed SQL
database engine in the world.
There's a LINQ provider for it called DBLinq
As #Robert Harvey pointed out in his answer there's (almost) full support for EF since there's an ADO.NET provider for SQLLite:
Support for the ADO.NET 3.5 Entity
Framework
Supports nearly all the
entity framework functionality that
Sql Server supports, and passes 99% of
the tests in MS's EFQuerySamples demo
application.

Generally, you want to store the data from your application in a database. For WPF and C#, that database is usually SQL Server or SQL Server Express, because Visual Studio 2008 easily integrates with those.
Do not use XML for this. XML is not intended to be a large scale storage medium; the purpose of XML is to provide a common language for different computer systems to talk to each other.
SQL Server Express is usable on any Windows PC; you just need to deploy the redistributable, using a named instance. See also http://msdn.microsoft.com/en-us/library/dd981032(SQL.100).aspx. If it's a small application and you want to go simpler, you can use SQL Server Compact Edition, or SQLite with the ADO.NET provider.

SQL Server CE 3.5 SP1 Stored Procedures

I have been tasked with taking an existing WinForms application and modifying it to work in an "occasionally-connected" mode. This was to be achieved with SQL Server CE 3.5 on a user's laptop and sync the server and client either via SQL Server Merge Replication or utilizing Microsoft's Sync Framework.
Currently, the application connects to our SQL Server and retrieves, inserts, updates data using stored procedures. I have read that SQL Server CE does not support stored procedures.
Does this mean that all my stored procedures will need to be converted to straight SQL statements, either in my code or as a query inside a tableadapter?
If this is true, what are my alternatives?

Since SQL Server CE is considered to be an "application data store", it is assumed that any complex logic that you might normally implement in a SQL Server Stored Procedure will be implemented in the application itself. Many traditional database concepts are not supported in SQL CE, such as constraints, covering indexes, stored procs, UDFs... you name it, SQLCE doesn't have it!
Because SQL CE is single-user, this assumption more-or-less makes sense; you don't really need to worry about concurrency or atomicity issues when you have total control over everything that's happening at the DB level. It helps to not really think of SQL CE as a full-fledged database; it's more of an alternative to something like SQLite or MS Access.
Your only options are:
Rewrite your application to behave differently (i.e. use simple queries or direct table access) when operating in "disconnected" mode;
Disallow the application from performing the more complex operations unless it is "connected";
Switch to SQL Express instead, which has a much larger footprint but does support Stored Procedures and most of the other SQL Server goodness.

Yes, they are not supported, and the best way is to build them into parameterized queries in code. You can build your own kind of framework for accessing them like stored procedures by enum and then keep them in one clean place in code.
Although if you plan on scaling sql compact at all (outer joins of multiple tables with thousands of rows) you will want to use SqlCeResult sets and the Seek method. It is extremely fast and you can even open indexes directly and seek on them.
http://msdn.microsoft.com/en-us/library/system.data.sqlserverce.sqlceresultset(VS.80).aspx

Another option is to use Linq to Datasets. It can "store" stored procedure like methods for you. It is not stored on the database, but it gives you that illusion (though all of these methods need to be attached to a table and still need to me fairly simple).

Another alternative is VistaDB. It does support T-SQL Procs and all the same datatypes as SQL Server (more than SQL CE actually).
You may want to look at this SO post on advantages of VistaDB for more information.

To my Mind you can make separate class in your database which could be assessed from Data Access Layer.
You can simply manage parameters collection in DAL and then pass them as object to Stored Procedure class Method which will behave like SQL Store Procedure and generate Query after Concatenation with desired variables.
After Generating Script it will return Query which can then pass to SQL CE to extract results.