>>>Hi Mike,
>>>>
>>>>I know where you're coming from - I came from the same place 6 months ago. I've since been fully commited to learning an ORM and haven't looked back. Most (maybe all?) ORMs use parameterized queries which eliminates SQL Injection capabilities. You can still create and call Stored Procedures from ORMs, but it's kind of a low value (unless it fits your requirements) task.
>>>
>>>I am wondering however too about the benefits of a SP being outside the application domain and thus allowing updates, tweaking, or modifications made more readibly. But then I think, they should be well established by this time and probably many changes require a change in the program as well. I don't know now but still pondering.
>>
>>In my DBA role I frequently make back-end changes to table structures, functions, and constraints. Since all my major data handling is done through stored procedures, this rarely requires application changes.
>>
>>This is my primary reason for using Stored procedures almost without exception.
>>
>
>I have to say if I was in your position I would do exactly the same. I think making changes to table structures just depends on the change and use in the application but would of course not always require an application change. Thanks for the input from your position and I agree. Stored procedures have always been a good idea but I am going to weigh this against EF. There are times of course where an application uses SQL Express data and there is no other access or use to the data where maybe it would be acceptible to skip the stored procedures assuming that does make it easier.
>Thanks
>Tim

But, when it is LinqToEF would it matter? Same thing, you could use SP or not and still your code doesn't change. IOW you could do today without SP and then decide to use SP. Your Linq powered code would still be the same (you only update your EF model).
Cetin