I've just been researching the ActiveRecord pattern, and based on this (http://en.wikipedia.org/wiki/Active_record_pattern), it seems Linq 2 Sql more or less implements this, am I wrong? or what would need to be changed for it to conform to the ActiveRecord pattern?
LINQ to SQL itself isn't an implementation of the ActiveRecord pattern. In a true implementation of Fowler's ActiveRecord pattern, the object itself would be responsible for saving and loading its state from the database. When using LINQ to SQL Objects, the DataContext is responsible for database retreival, tracking object state, and saving those changes back to the database.
You'd have a hard time wrapping those LINQ to SQL classes in more code to make it a true implementation of the ActiveRecord pattern (there's no easy way to take the responsibility away from the DataContext).
In some ways it can feel like an active record pattern, but it really isn't. Basic example:
//load the entity
var c = myDataContext.Customers.FirstOrDefault(c => c.Id == 1876);
c.Name = "George Armstrong Custer";
// saves the entity
myDataContext.SubmitChanges();
Active record
//load the entity
var c = Customer.GetCustomer(9);
c.Name = "Varus";
//save the entity
c.Save();
Active record really just involves one class which covers the model and supplies the data interface Linq to Sql follows a different path where there are a few model classes and a separate data interface, otherwise known as a repository.
PS: For a good example of an ORM that uses the active record pattern, check out Subsonic.
LINQ to SQL is not an implementation of Active Record, which would mean the entities are fully responsible for managing their own persistence (i.e. Persistence Aware). What LINQ to SQL actually is is an implementation of Unit of Work. A Unit of Work means that some kind of registry or context tracks the state of entities, either implicitly or explicitly, allowing entities to be completely ignorant of their persistence mechanism (i.e. Persistence Ignorant).
Unit of Work support a programming style called POCO (plain old clr object), which helps you maintain separation of concerns and maintain the principle of single responsibility. When those two principals are met, your software is usually easier to maintain. Active Record actually breaks both of those principals, leading to more tightly coupled software that can be more difficult to maintain.