We Keep Coding

LINQ to Entities v/s ADO.Net

Can LINQ to Entities entirely replace ADO.Net technology?
What I really want to know is, Is it possible to achieve every features and functionality that ADO.Net provides by using LINQ ? Who is the Boss?

Since you said in your comment that you mean LINQ to Entities, I will answer thus:
LINQ to Entities internally use ADO.Net, so it would be impossible for LINQ to Entities to replace ADO.Net, because it uses it. However I am assuming that you mean to ask if you can use LINQ to Entities in every situation that you could use ADO.Net. The answer is no, you cannot.
There are cases that you would not want to (or could not) use LINQ to Entities. For example if you are in a certain situation where you need better performance for a query, it would be better to use a stored procedure. Generally LINQ to Entities is a better choice when developer productivity has a higher priority than the execution speed of queries. Other cases where LINQ to Entities is not a good choice is when a DB has been poorly designed and does not have a primary key for example.
But the main point I think is this: What has higher priority in your situation? Developer productivity or performance? It is also quite acceptable I think to use both technologies. Complete the project with LINQ to Entities, and if there are performance issues, use stored procedures or ADO.Net.
Also, I would not use LINQ to Entities for large queries, or queries that have many joins, LINQ syntax for joins is not very terse, and may hurt the readability of your code.

#Reddy, it entirely depends on the scenario where you are deciding which technology to use. ADO.NET gives you tuple structure using DataSet at its focus and is used even day compared to ORM like tech i.e. LINQ-Entity. I have refrained to ADO.NET when the prime aspect of the application revolves around record processing, used in the SSIS pipeline but have stuck to LINQ-Entity when I primarily follow Test Driven Development or Domain Driven Development approaches.

1)ADO.NET is the database connectivity technology, so we can use ado.net to do operations with only Databases , but if we get a requirement to get the data from non database datasources like xml,collections etc.. its not possible.
But using LINQ it is possible to get data from many datasources like collections, XML files, Entities, even with Databases also.
2) But if you come to the performance wise ADO.NET is very faster than any other database connective technologies.
3) If you go with LINQ Run time errors can be rectified so bugs will be less ,so reliability increases
so ADO.NET vs LINQ technologies both having their own positives and negative features ,Microsoft given huge amount of featured technologies, so according to the application requirement we need to go with that technology.

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.

Entity framework running sprocs and native queries performance considerations

I'm wondering if there's a performance penalty when doing the following vs using plain old ado.net DataReader and DataTable:
using(DBEntities dbEntities = new dbEntities)
{
ObjectResult<tblCustomers> customers =
dbEntities.ExecuteStoreQuery<tblCustomers>("SELECT name,id FROM tblCustomers");
}
I would also like to run sprocs using dbEntity.
I mention this because i'm developing a highly performance sensitive application but would still like to use the entity framework.
furthermore, can anyone point me to recent performance tests of linq to entities compiled queries on .net 4.0?
EDIT
If i go with ado.net i plan on inserting the results i get from each row to a .net object manually. So it's entity framework storequery/sproc vs ado.net + manually creating and inserting data to a .net object.

Yes, of course - this is a higher-level approach than plain ADO.NET / SQL.
You send in a SQL query and get back a list of tblCustomers objects. Somewhere along the line, a mapping from the database's row/column to the object will happen, and this does take some time.
On the other hand - if you want to do the same thing yourself, you will have to pay a performance penalty, too - or you just use the old-style row/column to do your work (not recommended!).
It's the classic "convenience vs. performance" trade-off - what is more important to you? Being able to program with nice C# objects and their properties and be very productive as a programmer - or a few nanoseconds on the SELECT from your database? It's your pick....

Linq with multiple RDBMS type

I have heard that Linq query write once can be run on SQL and MS Access database too. Is it right or wrong?
For example I want to write queries once regardless of database type like currently I'm using MS Access database and later then if I wish to move on to SQL Server then I don't want to change my queries. Is this possible??

It depends in part on the queries. For simple queries (select, where, orderby) you should be fine, but there are a lot of implementation-specific details.
For example:
taking a First on a set you haven't explicity ordered : LINQ-to-SQL is fine with that, LINQ-to-Entities will fail
using an Expression.Invoke to build a gnarly custom expression : again, LINQ-to-SQL is fine, LINQ-to-Entities will fail
using things like UDFs - in addition to LINQ-to-Entities not supporting it, your RDBMS might not support it
with "Astoria" (LINQ to data services), there were some scenarios around .Where(predicate).FirstOrDefault() vs .FirstOrDefault(predicate) - which are semantically identical, but IIRC only one works (in Astoria)
My point is; it might work, but you do need to test against the specific implementation.

LINQ-to-SQL will only work with SQL server. Linq to objects will work on most any collection, but you lose the deferred execution.

If you use Entity Framework, you can find/buy several provider for different data sources.
As soon as you have enough abstraction over the entity context, you can use any LINQ construct to build your queries. But keep in mind that not all providers support the same operators and functions. You will still have to test the complete application during a DBMS change.

Basically, you can use Linq to Objects and work with any dataset.
If you want to save your logic and specific - I recommend you to use Devart LinqConnect.
Also, you can read more about simultaneous Oracle and MS SQL usage in given article. Approaches will be the same for LinqConnect.

How can I leverage an ORM for a database whose schema is unknown until runtime?

I am trying to leverage ORM given the following requirements:
1) Using .NET Framework (latest Framework is okay)
2) Must be able to use Sybase, Oracle, MSSQL interchangeably
3) The schema is mostly static, BUT there are dynamic parts.
I am somewhat familiar with SubSonic and NHibernate, but not deeply.
I get the nagging feeling that the ORM can do what I want, but I don't know how to leverage it at the moment.
SubSonic probably isn't optimal, since it doesn't currently support Sybase, and writing my own provider for it is beyond my resources and ability right now.
For #3 (above), there are a couple of metadata tables, which describe tables which the vendors can "staple on" to the existing database.
Let's call these MetaTables, and MetaFields.
There is a base static schema, which the ORM (NHibernate ATM) handles nicely.
However, a vendor can add a table to the database (physically) as long as they also add the data to the metadata tables to describe their structure.
What I'd really like is for me to be able to somehow "feed" the ORM with that metadata (in a way that it understands) and have it at that point allow me to manipulate the data.
My primary goal is to reduce the amount of generic SQL statement building I have to do on these dynamic tables.
I'd also like to avoid having to worry about the differences in SQL being sent to Sybase,Oracle, or MSSQL.
My primary problem is that I don't have a way to let ORM know about the dynamic tables until runtime, when I'll have access to the metadata
Edit: An example of the usage might be like the one outlined here:
IDataReader rdr=new Query("DynamicTable1").WHERE("ArbitraryId",2).ExecuteReader();
(However, it doesn't look like SubSonic will work, as there is no Sybase provider (see above)

Acording to this blog you can in fact use NHibernate with dynamic mapping. It takes a bit of tweaking though...

We did some of the using NHibernate, however we stopped the project since it didn't provide us with the ROI we wanted. We ended up writing our own ORM/SQL layer which worked very well (worked since I no longer work there, I'm guessing it still works).
Our system used a open source project to generate the SQL (don't remember the name any more) and we built all our queries in our own Xml based language (Query Markup Language - QML). We could then build an xmlDocument with selects, wheres, groups etc. and then send that to the SqlEngine that would turn it into a Sql statement and execute it. We discusse, but never implemented, a cache in all of this. That would've allowed us to cache the Qmls for frequently used queries.

I am a little confused as to how the orm would be used then at runtime? If the ORM would dynamically build something at runtime, how does the runtime code know what the orm did dynamically?
"have it at that point allow me to manipulate the data" - What is manipulating the data?
I may be missing something here and i aplogize if thats the case. (I only have really used bottom up approach with ORM)

IDataReader doesn't map anything to an object you know. So your example should be written using classic query builder.

Have you looked into using the ADO.NET Entity Framework?
MSDN: LINQ to Entities
It allows you to map database tables to an object model in such a manner that you can code without thinking about which database vendor is being used, and without worrying about minor variations made by a DBA to the actual tables. The mapping is kept in configuration files that can be modified when the db tables are modified without requiring a recompile.
Also, using LINQ to Entities, you can build queries in an OO manner, so you aren't writing actual SQL query strings.