>So, you've played with Linq to SQL, that's good. But, have you actually tried it for real, not just putting all that stuff on a Form (we all know that's not "best practice"). You've got to have the SQL connection string stored somewhere. You've also got to make it easily configurable (no hard-coded stuff!) ... it's been a few years since I tried Linq and I didn't think at the time it was the way we wanted to go. But, it was still new then and not fully developed ... maybe they addressed the issues I had with it at the time, but I'm sorry to say that I never went back and re-visited it (haven't had the time really).
>
>~~Bonnie
>


Hey, I'm no expert here, and I *DO NOT* know which way I need to go, so I am just playing with everything to see what I can learn.

Anyway, regarding Linq-To-Sql, it seems pretty well abstracted as far as all that goes. There is a .dbml file that has the connection info in it, as well as the schema for each table and relationships between them all.

You can assign/override the ConnectionString with somthing like this: db.Connection.ConnectionString="........"

It makes class definitons (types) for each table in the database, and then you can create (add) methods to each class (in a partial class code file) to create the DAL methods that you use from the presentation layer:

    public partial class Job
    {
        public IEnumerable<Job> GetActiveJobsByCustID(string CustID)
        {
            DataClasses1DataContext db = new DataClasses1DataContext();
            if (CustID != null)
            {
                IEnumerable<Job> JobRecords = from a in db.Jobs
                                              where a.cust_num == CustID && a.status == 'A'
                                              orderby a.priority, a.job_num
                                              select a;

                return JobRecords;
            }
            else
            {
                return null;
            }
        }
    }