Mike,

>>I am coming to the same conclusion. SQLDataSource is easy to use, you can set up data binding with drag and drop and setting some simple properties, but the GUI is bound directly to a specific database. Not only are you then tied into a specific front end and a specific back end, a business objects tier (if you have one) is out of the loop completely.<

< SET RANT ON >

OK, I'm not ranting at *you* per se, but this is one of my biggest pet peeves ... drag and drop programming I call it. I cannot for the life of me understand why every sample and walkthrough you read advocates dragging and dropping database connection stuff directly on your Forms!!! This a *big* no-no and yet you read about it everywhere!! Drives me nuts!

< SET RANT OFF >

Phew! I'm much better now. <g>

~~Bonnie




>>I've been reading a book that makes a strong argument for using typed datasets in 2.0. Since they've fixed a lot of problems with the implementation in 1.0.
>>
>>But Rick Strahl's comments when discussing the issue here with Bonnie made sense. When you use typed datasets VS generates a ton of code for you, good thing.
>>
>>However, it's still a ton of code that must run. Not too big a problem on a desktop app. But a real big problem on a web app. And one of the big selling points of dotnet is you should be able to create an app that can easily have the UI replaced. You should be able to go from desktop to Web to Web services easily. I think you need to use Object Data Binding to make this work correctly.
>>
>
>I am coming to the same conclusion. SQLDataSource is easy to use, you can set up data binding with drag and drop and setting some simple properties, but the GUI is bound directly to a specific database. Not only are you then tied into a specific front end and a specific back end, a business objects tier (if you have one) is out of the loop completely.
>
>SQLDataSource was already a dead end for me because we have a requirement to support Oracle as well as SQL Server. SQLDataSource supports multiple back ends but you have to choose one, and then you are tied to that database's OLEDB or ODBC provider. I am looking into the Generic Factory Model, which is new in the .NET 2.0 framework. Apparently it will do exactly what I need. Now all I have to do is figure out how ;-)