>Hey Dmitry,
>
>>Not only you can make a suggestion but I very much appreciate it. Now, that you mentioned separating DataAccess and Typed DataSet, I am confused <g>. If DataAccess does not have Typed DataSet, what is specifically in DataAccess? Can you give me a pseudo code or maybe (if you have time) a few lines of actually code that belongs in DataAccess class?
>
>The DataAccess class can *use* the DataSets, but it gets to them via a reference to another project, the DataSet project, which is where the DataSets would actually live.
>
>IOW, the only purpose of your DataAccess classes is to get/save data from/to your database via DataAdapters and Commands. For example, in your GetMyData() method, you would instantiate a Typed DataSet and then use the DataAdapter's .Fill() method to fill the DataSet from the database.
>
>Does that help?
>

I don't know <g>. I am reading the book "Data Binding with Windows Forms 2.0" by Brian Noyes and at the same time trying to build a Win Form that will get data from DB, bind it to the controls on the form, and allow changes to be sent back to DB. So far I have read the chapter that describe how to create a Typed DataSets and now reading the chapter describing on how to bind properties of the typed data set to UI controls. He (the author) calls the project that has typed dataset as DataAccess project. The SQL Server connection (in the book) seem to be part of this project of typed data sets. I understand that you are saying that conceptually (and probably in assemblies) the DA should be separated from the typed data sets. I think (if I get it) you would refer to the project of typed data set as BIZ layer instead of Data Access layer. But I need to learn the mechanics of separating these two. I will keep reading the book and will try to figure out the details.

Thank you.