We Keep Coding

Is there any way in .NET, other then Oledb to be database independent

Is there a way my DAL classes can be re used across different databases ?
I know some technologies (Linq and EF) support rapid development, I appreciate this feature but I also want to keep my DAL Code reuse able in different database.
A Simple thing that come to mind is use of Oledb with inline SQL queries, Is there a more elegant way ? please guide me. I am just considering 2 things.
support to 4 most commonly used databases (SQL Server, My SQL, Access, Oracle).
Rapid development support.
Thanks

You may consider using an ORM framework such as Entity Framework or NHibernate. This way your data access layer will be database agnostic.

If you stick to the interfaces (IDbConnection, IDbCommand, ...) and their factory methods (IDbConnection.CreateCommand) then the only code that needs to know what database you are using is the initial connection creation (which can be encapsulated).

Entity Framework does the work you want. The most commonly used databases support it, with the exception of Oracle. For Oracle, you have to use third-party components as the official Oracle support for Entity Framework is still in beta.

NHibernate with Firebird... are these features enabled?

We're using NHibernate to great success with a Firebird backend. My question relates to the features available in NHibernate being supported by Firebird. If you have any expertise with Firebird and NHibernate your comments are welcome.
Does Firebird support "Future" queries? From my reading it would appear that Firebird is one of a few databases that doesn't support this feature. Does anyone have a workaround as "Future" would be a good feature to utilise.
Does Firebird support the NHibernate feature "prepare_sql". For some reason I cannot get this to work in Firebird and continually receive the warning (in Nhibernate Profiler) about parameter sizes not being equal.
Does Firebird support batching? In NHibernate mappings we specify batching however cannot see any evidence of this in the profiler.
For those interested we are using Fluent NHibernate to configure NHibernate. Everything works well and we have a great deal of control over the ORM however just need clarification on the above items.
Your thoughts?

As far as I know batching is supported only for MsSql and Oracle. Not even MySql has batching support.
You can always download NH source code and take a look if these features are supported.
IMO firebird is not very popular in recent years and it is possible that there is not much interes in bringing these features in NH for firebird.

"Future" is a feature of NHibernate. From what I understood by reading about futures the database feature needed would be to send multiple statements in one batch (round-trip) to the server and receive the results back in one batch, too.
I think Firebird doesn't allow this, since you have to prepare and execute statements individually.
Though if you only do insert/update/delete you could group those statements within an execute block statement, but that can only return one result set.
To get a definitive answer be sure to ask this in the firebird-support mailing list.

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.

one Library for multiDatabases

Im developing a windows forms application using C# 4.0 and that application is going to target different database engines like SQL, MySQL and Oracle i was wondering if there is a library that can talk to all the three engines instead of implementing my own layers for every one.
thanks in advance.

You could use an ORM tool; I like NHibernate But there are many more: see a list at wikipedia.

The problem is if you want to do anything remotely advanced (date arithmatic, generate primary keys, get the id of the last inserted record, pivot a table , use RANGE construct etc.) then both databases use completely different syntax.
The best solution (in the java world at least is either Ibatis or Hibernate) I know there is a .NET version of Hibernate I am not sure about Ibatis.
These libraries insulate your program from the various SQL dialects and provide a common API independent of the underlying database.

If you use the classes in System.Data.Common you can make your code database independent:
Writing Provider Independent Code in ADO.NET

I don't know C#, but I know it will have a library for ODBC.
It looks like MS has one here.
It's old, but actually it does the job just fine. Virtually every DB in existence provides an ODBC driver.

Checkout DbLinq.
DbLinq is THE LINQ provider that allows to use common databases with
an API close to Linq to SQL. It currently supports (by order of
appearance): MySQL, Oracle, PostgreSQL, SQLite, Ingres, Firebird...
And still SQL Server.

Which is the "best" data access framework/approach for C# and .NET?

(EDIT: I made it a community wiki as it is more suited to a collaborative format.)
There are a plethora of ways to access SQL Server and other databases from .NET. All have their pros and cons and it will never be a simple question of which is "best" - the answer will always be "it depends".
However, I am looking for a comparison at a high level of the different approaches and frameworks in the context of different levels of systems. For example, I would imagine that for a quick-and-dirty Web 2.0 application the answer would be very different from an in-house Enterprise-level CRUD application.
I am aware that there are numerous questions on Stack Overflow dealing with subsets of this question, but I think it would be useful to try to build a summary comparison. I will endeavour to update the question with corrections and clarifications as we go.
So far, this is my understanding at a high level - but I am sure it is wrong...
I am primarily focusing on the Microsoft approaches to keep this focused.
ADO.NET Entity Framework
Database agnostic
Good because it allows swapping backends in and out
Bad because it can hit performance and database vendors are not too happy about it
Seems to be MS's preferred route for the future
Complicated to learn (though, see 267357)
It is accessed through LINQ to Entities so provides ORM, thus allowing abstraction in your code
LINQ to SQL
Uncertain future (see Is LINQ to SQL truly dead?)
Easy to learn (?)
Only works with MS SQL Server
See also Pros and cons of LINQ
"Standard" ADO.NET
No ORM
No abstraction so you are back to "roll your own" and play with dynamically generated SQL
Direct access, allows potentially better performance
This ties in to the age-old debate of whether to focus on objects or relational data, to which the answer of course is "it depends on where the bulk of the work is" and since that is an unanswerable question hopefully we don't have to go in to that too much. IMHO, if your application is primarily manipulating large amounts of data, it does not make sense to abstract it too much into objects in the front-end code, you are better off using stored procedures and dynamic SQL to do as much of the work as possible on the back-end. Whereas, if you primarily have user interaction which causes database interaction at the level of tens or hundreds of rows then ORM makes complete sense. So, I guess my argument for good old-fashioned ADO.NET would be in the case where you manipulate and modify large datasets, in which case you will benefit from the direct access to the backend.
Another case, of course, is where you have to access a legacy database that is already guarded by stored procedures.
ASP.NET Data Source Controls
Are these something altogether different or just a layer over standard ADO.NET?
- Would you really use these if you had a DAL or if you implemented LINQ or Entities?
NHibernate
Seems to be a very powerful and powerful ORM?
Open source
Some other relevant links;
NHibernate or LINQ to SQL
Entity Framework vs LINQ to SQL

I think LINQ to SQL is good for projects targeted for SQL Server.
ADO.NET Entity Framework is better if we are targeting different databases. Currently I think a lot of providers are available for ADO.NET Entity Framework, Provider for PostgreSQL, MySQL, esql, Oracle and many other (check http://blogs.msdn.com/adonet/default.aspx).
I don't want to use standard ADO.NET anymore because it's a waste of time. I always go for ORM.

Having worked on 20+ different C#/ASP.NET projects I always end up using NHibernate. I often start with a completely different stack - ADO.NET, ActiveRecord, hand rolled wierdness. There are numerous reasons why NHibernate can work in a wide range of situations, but the absolutely stand out for me is the saving in time, especially when linked to code generation. You can change the datamodel, and the entities get rebuilt, but most/all the other code doesn't need to be changed.
MS does have a nasty habit of pushing technologies in this area that parallel existing open source, and then dropping them when they don't take off. Does anyone remember ObjectSpaces?

Added for new technologies:
With Microsoft Sql Server out for Linux in Beta right now, I think it's ok to not be database agnostic. The .Net Core Path and MS-SQL route allows you to run on Linux servers like Ubuntu entirely with no windows dependencies.
As such, imo, a very good flow is to not use a full ORM framework or data controls and leverage the power of SSDT Visual Studio Projects (Sql Server Data Tools) and a Micro ORM.
In Visual Studio you can create a Sql Server Project as a legit Visual Studio Project. Doing so allows you to create the entire database via table designers or raw query editing right inside visual studio.
Secondly, you get SSDT's Schema Compare tool which you can use to compare your database project to a live database in Microsoft Sql Server and update it. You can sync your Visual Studio Project with the server causing updates in your project to go out to the server. Or you can sync the server with your project causing your source code to update. Via this route you can easily pick up changes the DBA made in maintenance last night and push out your new development changes for a new feature easily with a simple tool.
Using that same tool you can compute the migration script without actually running it, if you need to pass that off to an operations department and submit a change order, it works for that flow to.
Now for writing code against you MS-SQL Database, I recommend PetaPoco.
Because PetaPoco works Perfectly inline with the above SSDT solution. PetaPoco comes with T4 text templates you can use to generate all your data entity classes, and it generates the bulk data layer classes for you.
The catch is, you have to write queries yourself, which isn't a bad thing.
So you end up with something like this:
var people = dbContext.Fetch<Person>("SELECT * FROM People where Username Like '%#0%'", "bob");
PetaPoco automatically handles parameterizing #0 for you, it also has the handy Sql class for building queries.
Furthermore, PetaPoco is an order of magnitude faster than EF6 and 8+ times faster than EF7.
So in total, this solution involves using SSDT for SCHEMA management, and PetaPoco for code integration at the gain of high maintainability, customization, and very good performance.
The only downfall to this approach, is that you're hard tieing yourself to Microsoft Sql Server. However, imo, Microsoft Sql Server is one of the best RDBM's out there.
It's got DBMail, Jobs, CLR object capabilities, and on and on. Plus the integration between Visual Studio and MS-SQL server is phenomenal and you don't get any of that if you choose a different RDBMS.

I must say that I never used NHibernate for the immense time that needed to start using... time wasted on the XML setup.
I recently did a web application in MVC2, where I did choose ADO Entities Framework and I use Linq all the time.
I must say, I was impressed with the speed! and our site was having around 35 000 unique visitors per day, in around 60Gb bandwidth per day (I reduced radically this 60Gb number by hosting all static files in Amazon S3 - Great .NET wrapper they have, I must say).
I will always go this way. It's easy to start (just add new data item, choose tables and that's it! for every change in the database we just need to refresh the model - made automatically in just 2 clicks) and it's fun to use - Linq rules!