Active Record is a design pattern for data access...
At the moment there are two main design patterns I seem to come across regarding data access: ActiveRecord and the Repository Pattern
Active Record
Your objects contain methods for persisting their state to a DB (or other persistence mechanism) so:
You may have a Customer object.
Customer object will have a bunch of methods like Customer.Save();, Customer.Get(int id); and others.
These methods do not really have anything to do with a customer in the real world. They are really about the infrastructure of your application.
Repository Pattern
In repository pattern, your customer object would be a POCO, or dumb object. It only has methods and properties that it really needs to represent a customer (things like name, email address, List orders, etc.)
When you want to persist the customer - you simply pass it to your repository
Repository.Save(MyCustomer).
The Active record pattern is quick and easy to work with. Unfortunately, it does clutter up your domain model with these methods which do not really have anything to do with a Customer. This makes it slightly harder to maintain your domain model over time.
For a lot of situation it is very appropriate to use an Active record pattern. For example - If I'm writing a fairly simple app that is probably not going to change much, I'd probably fire up SubSonic and generate my an Active Record DAL. I'd be coding my business code within 20 minutes and all the DB stuff is taken care of already.
If, on the other hand, I am modelling a particularly complex domain, with high susceptibility to change, I'd rather keep my domain models clean, and implement a repository pattern with nHibernate or similar...
It's been a long time since I rolled my own data access using ADO.Net, and I don't really recommend it now there are so many great data access tools available.