Get the enterprise library 3.1 version.
It will abstract you "up one level", so you're not super tied to 1 rdbms.
(even though I don't consider access a true rdbms)
.......
Another option is to write a data-access-layer, via an interface.
Interface IEmployeeData
and then have 2 concrete versions of IEmployeeData
example:
interface IEmployeeData
IDataReader GetAllEmployees();
IDataReader GetSomeEmployess( Guid deptUUID ) ;
void UpdateEmployee ( Guid empUUID, string lastName , string
firstName , string ssn , Guid deptUUID ) ;
void DeleteEmployee ( Guid empUUID) ;
and then implement one for SqlServer, and 1 for Access.
public class EmployeeDataViaSqlServer : IEmployeeData
public class EmployeeDataViaAccess : IEmployeeData
Its called the Factory Design Pattern.
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!126.entry
http://www.dofactory.com/Patterns/PatternFactory.aspx
The reason I mention the factory pattern is because of the large differences
in ways you're going to code up a DAL for the two.
Sql Server has stored procedures, which most commonly you're gonna add
parameters to.
db.AddInParameter ( )
Access, you don't have stored procedures. So the code is going to look
different.
..........
I have done the IEmployeeData thing, and I use the Ent Library 3.1 within
that setup. I use the "key" model (my blog entry) to decide which concrete
version to give back.
But as long as your biz layer uses the IEmployeeData interface, you'll be
good. And you'll need to learn how to work with the IDataReader interface
instead of a concrete version.
