No, I know what you mean. The datasets need SOME method to perform CRUD operations. You can configure a dataset to use straight SQL statements, or you can configure them to use SPs. I think that the preferred method of a lot of people is to use SPs and datasets.

>Hi Mike,
>
>Thanks but I know that, I think I didn't make myself clear here. Few months ago, some people are saying to me that its better to use dataset in Inserting, Updating, deleting data instead of using SP.
>
>
>
>>SP's are on the database end and provide the data. Datasets are the containers or classes in the application that hold the data.
>>
>>>Hi Kevin,
>>>
>>>I'm quite happy that you have this blog "Why I prefer stored procs". Does this means that you prepare using SP rather than DATASET now?
>>>
>>>I still remember few months ago, some people here are saying that its better to use DATASET than SP.
>>>
>>>Regards
>>>
>>>>I'm gonna put this in my blog....basically, in no order of importance:
>>>>
>>>>- They provide an application/client-agnostic API for accessing the database.
>>>>
>>>>- Having an application-agnostic API for the database can really become beneficial in a corporate environment with several applications and developer teams.
>>>>
>>>>- If I had a dime for every time an I.T. manager breathed a sigh of relief when I told him/her that something could be added/changed/fixed simply by tweaking a stored proc (as opposed to having to update an application DLL), I'd have plenty of dimes.
>>>>
>>>>- I can abstract out and establish an API and build stored procs independantly of the application, and in many instances can make changes without disrupting the development environment
>>>>
>>>>- The new tools for building custom database unit tests in Visual Studio Team Edition for Database Professionals are outstanding. (If anyone is interested in building unit tests for stored procs, you HAVE to look at this product. It is fantastic).
>>>>
>>>>- It's much more difficult for a DBA to manage database code if it's residing inside application logic
>>>>
>>>>- SQL 2005 contains many new language features that are best utilized inside stored procs.
>>>>
>>>>
>>>>As I've said before, I use them as a strong starting point, unless there are good reasons for not doing so. In general, I believe that all external access to a database should occur through stored procs.
>>>>
>>>>Clients WANT me to use stored procs. I work with at least a few new I.T. teams each year, and I can't think of one that didn't want to use them. And when the ultimate decision is left to me, I use them on a regular basis.