Bonnie,

Thanks for responding again, and for referring to Kevin's response which I would otherwise have missed because I clicked on the button for today's messages expecting to get those sent in the last 24 hours, but no...

I imagine that y'all love the UT's interface, but I'd prefer simple e-mail handled by a list server. For example, there's a checkbox to forward this response to Kevin, as there was for you, but after I previewed my reply that option disappeared.

So, here's what I wrote to Kevin:

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.

Thanks,
David.


>Kevin supplied a good answer for me. I was in no way implying not to use DataSets!!! Sorry that you misunderstood!! I am a huge advocate of Typed DataSets. We use nothing but. Use .xsd's to define your DataSets. Visual Studio can then generate the proper files for your Typed DataSet.
>
>A trick we used early on to generate .xsd's for us was to use the DataSet.WriteXmlSchema("MyFileDataSet.xsd"). We wrote a little utility program that, after you told it what Stored Proc you wanted to use and what you wanted to name your DataSet, it would call the Stored Proc, Fill the DataSet, then write out the Schema to an .xsd file. You can then add that .xsd to your project (we typically have separate DataSet projects) and generate a Typed DataSet. You can then drop those on your Form (when you drag a DataSet from the ToolBox to your design surface, you'll get a wizard that will help you choose the Typed DataSet to add to the Form).
>
>~~Bonnie
>
>
>
>
>
>>Bonnie,
>>
>>Thanks very much. I agree with your programming philosophy 100%. The config file for connection strings is no problem, 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? I don't expect, or want, you to give me a detailed tutorial, but if you could point me to a source or two, I'd much appreciate it.
>>
>>Thanks again,
>>David.
>>
>>
>>>David,
>>>
>>>First, the auto-quote stuff. Look at the "Message view setup" tab at the top right of this message "pane". Hover your mouse over that and you should see an option to "Enable auto quote".
>>>
>>>Now, the second thing is the TableAdapters. Unfortunately what the TableAdapter paradigm does, is to tie your DataSets/DataTables directly to your backend data. This is not good, IMHO. DataSets are meant to be a disconnected representation of your data. In my opinion, a DataSet should know nothing about where it's data came from. That is the job of the DataAccess layer of your application to figure out: the DataAccess layer makes the connection to the database, fills the DataSet, and then passes the DataSet back to the front-end UI layer (either directly via a Biz object or through a Web Service).
>>>
>>>In this way, it's easy to swap out your DataAccess layer to connect to another database server (say, switching from SQL Server to Oracle), without it ever affecting your DataSets. And by having your connection strings in a config file, it's also very easy to switch your connections from one database to a different one on the same server (say, switching from a test database to the real production database). You DO NOT want this stuff hard-coded in the application. Sorry, but that's just not the way it should ever be done.
>>>
>>>~~Bonnie
>>>
>>>
>>>
>>>
>>>
>>>>Bonnie,
>>>>
>>>>Thanks for the reply. Yes, I do have connection strings hard-coded in my application, and yes, I did let Visual Studio create all this stuff for me including the TableAdapters but everything has worked fine so far except for this tedious waiting while Visual Studio does something with the Dataset in the new location.
>>>>
>>>>I look forward to hearing more from you, but since the connection strings aren't causing me any problems, I don't see how putting them in a config file will speed things up.
>>>>
>>>>Cheers,
>>>>David.
>>>>P.S. If you could also tell me how to quote your message (i.e. the one I'm replying to), I'd appreciate that too.