The problem I have is that while Employees exists in the context, Employee does not. In all the examples I have seen, this just seems to work. Any help would be appreciated, thanks.
Most likely the table is called Employees rather than Employee, because that's how is was defined in SQL Server.
There's an easy way to tell: In the Schema Explorer, hover over Employees and look at the tooltip.
Thanks for the reply, Joe. I see that it does work fine if I instantiate a new Employees object as opposed to an "Employee", thank you. The table was indeed named Employees in the database.
I suppose I'm just getting confused because things are structured a little differently than I'm used to seeing, probably because I'm using LinqPad with the database directly as opposed to working with an EF model. I've been using EF's DbContext with DbSets like Employees, Tasks, Clients while using the singluar (Employee, etc..) for the model classes, which makes sense for me. I don't have any experience with LinqToSql, so I'm not sure if this is convention for LinqtoSql, or the way pluralization is working, or just some fundamental concept in LinqPad that I don't understand.
Anyway, thank you for the reply and the program, which I really like.
LINQPad pluralizes the collection properties if your table names are singular, but it doesn't attempt to singularlize plural names, because I never got round to writing a singularizer.
Pluralization and singularization is a function of the tooling. It's not really related to whether you use LINQ-to-SQL or EF.
Ah.. thanks Joe, makes sense to me now.