>Hi Kevin,
>
>>1. You can place the SQL statements in the data access class. If you do this, I recommend using a bridge pattern. For example, you could create a method on the business object named "GetOrdersByCustomerID", and create a corresponding method on the data access object named "GetOrdersByCustomerID". The method on the business object passes the call on to the data access object that contains the actual SQL SELECT command. This is the "purer" approach, but requires a little extra work.

>Would you please show me the code (c#) of the business object method using this approach?

Sure...

1. Follow the steps in the MM .NET Dev Guide for creating a custom data access class. For the sake of this example we will call the data access class "OrdersDataAccessSql". In order generically reference any data access class associated with the business object, you should create an IOrdersDataAccess interface that all your data access classes implement. This interface needs to contain all the custom methods you add to each data access class.
   
   
2. Add a new method to the data access class. For example:

   public DataSet GetOrderByOrderID(int orderID)
   {
   	return this.GetDataSet("SELECT * FROM Orders WHERE OrderID = @OrderID",
   		this.CreateParameter("@OrderID", orderID));
   }

3. Add a method named GetOrderByOrderID() to the business object. This method passes the call on to the data access object. For example:

   public DataSet GetOrderByOrderID(int orderID)
   {
   	// Get a reference to the data access object, casting it to the IOrdersDataAccess interface
   	IOrdersDataAccess dao = (IOrdersDataAccess)this.GetDataAccessObject();
   	return dao.GetOrderByOrderID(orderID);
   }

Honestly though, it's better (and easier) to use stored procedures and place all your database-specific code in the database.

Regards,