Kevin,

Thanks for jumping in. If I understand you correctly, you're recommending the use of DataSets but not TableAdapters. I'm flattered that you think I design them - all I do is pick the tables and columns thereof whose data I want to appear in the form and VS and/or VB does the rest...

BTW, I'm just starting to get my feet wet in VB (as if you haven't noticed!) after years of VFP, so I'm most comfortable with building my SQL command and then issuing a ExecuteNonQuery(), just like good old SQLPassThrough. In VFP, I was doing fine with version 6, but then ran into problems with the CursedAdapters (as I called them) that were introduced with VFP8. Maybe I can only handle one or two levels of abstraction...

I'll do some experimenting on Sunday and see what I can learn then.

Regards,
David.

>... but how do I avoid using DataSets when Visual Studio makes them so damn seductive by having them do so much just by dragging them onto a form?
>
>Hi, David,
>
>Sorry to jump in, I know Bonnie will be happy and able to give you a further explanation, but I wanted to respond:
>
>Nothing that Bonnie has said means you have to avoid DataSets - typed DataSets are a nice visual representation of the data, and yes, they help with the design-time experience in Visual Studio. What Bonnie is specifically voicing opinion on (and I definitely agree with her) is the use of the TableAdapter. It's OK (in my book) to use typed DataSets - you just don't want to design them to be coupled/tied to your data access in the manner you were describing. From your posts, it sounds like you're carrying too much coupling in your project.