>Thomas, that's what I'm thinking. One of the things Linq should do is allow a better tier split between database and business logic compared to use of SP as "best practice". But why stop there? These are all man-made rules and often they're just a set of standardizations, justifying curiosity from students like me. ;-)

John,

the area is littered with interaction... The tendency of oracle dev's to be less than enthusiastic is something I would have bet on without long thinking just because it puts fear in the only mediocre part of devs.
Regarding SP vs. Biz layer as the "correct" layer: I tend to prefer the biz layer, because it enables your company to assimilate others - but I also must be honest to say the competence of DBA's compared to normal developers favors DBA's - the percentage of total dunderheads is markedly lower in my expirience.
So "where to put the split" is also not a clear cut area. I see LINQ as a great way to abstract the manipulation code from the currently used data storage - encompassing memory structures for middle tier access, SQL everywhere for file based embedded storage in the middle tier up to LINQ for SQL to talk to interchangeble backends. For the tasks I am often called in (optimizing, streamlining and refactoring) interchangeble storage structures scratch my bigest itch I had with ADO.Net, and put .Net ahead of vfp in an area important to me. There are still ample areas where I prefer the fox way (dynamimism and my own laziness-enhanced use of basic SQL<g>) but the .Net story is growing.

regards

thomas