Well, how else are you supposed to build a working application in a one hour demo? ;-)

No offense taken....


>Mike,
>
>I understand ... that's why I said my rant was really not directed at you. For seasoned programmers, we quickly see that dragging connection info to a form is not a good idea. But I'm worried, because you see it advocated everywhere, that people who aren't that savvy will think that it's the only (or the best) way to do it.
>
>~~Bonnie
>
>
>
>>>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>
>>>
>>
>>I really wasn't advocating doing it that way. Just green with all this and discovering a lot of the pitfalls as I go along. Once I realized the drag and drop approach was tying me to a specific connection I knew that wasn't going to work. As it happens, today I am working on implementing a factory pattern to talk to the databases using the new dbProviderFactories stuff.
>>
>>OTOH I am all for drag and drop programming as long as it works. I don't feel the need to prove myself by doing things the hard way. I sure don't want to develop applications in Notepad.