Newbie Questions on ADO.NET in VB.NET(basically ADO.NET questions)

[SStory]

ok. I have a basic understanding of the dataset but still more questions
than answers.

For example, if you use the Server Explorer to create connections, and then
wizards to generate datasets...

1.) What if this is an app that you will redistribute and not a corporate
app where these connections are fixed? What do those GUI representations
really mean in terms of code and how do you allow the user to change where
that connection points--I.e. computername, sqlservername, database name
,etc.

2.) Isn't a dataset a lot of overkill? I get this dataset and load it with
separate tables with tons of data so that I don't have to reconnect to the
database--that is the purpose right? Then if that is a lot of data that is
a lot of network traffic and client memory used up right? Also if I get
just a portion of the data then if I want more I must hit the database again
anyway. Also, if I make updates then I have to write code to try to deal
with collisions.

What do you do if User A enters a lot of stuff and then User B does two...
both try to update the dataset to the database and one gets failures--does
that mean I tell him... sorry all your work for the last 30minutes couldn't
be done and dump it?

I guess I just don't get it.. Seems like a whole lot more work than
benefit. I have seen a few instances where I could see the dataset being
useful--like getting a bunch of data to just display and sort etc. But when
it comes to adding data etc. Seems teh direct approach with sqlcommands and
stored procs is more sensible.

Then do you just create a dataset for the whole project and use the same one
for each form--is it globally available, or is the xsd file just a spec that
I use to create a new one in each form as needed?

Am I totally lost here?

Any ideas would be appreciated. As you can see I know enough to be
dangerous but still fail to get the big picture and think that it all has to
be easier than what I can see and that also these GUI items in the IDE like
the Server Explorer have to make life easier... But I honestly haven't been
using it so far for my connections--just code--because I know what that does
and how to allow the user to change it.

Thanks,

Shane

 

[Bob Grommes]

I hand-code everything and am not familiar with the wizards. But I'll take
a stab at some of your questions inline:

2.) Isn't a dataset a lot of overkill?

Sometimes. For those situations we have DataReaders.

I get this dataset and load it with
separate tables with tons of data so that I don't have to reconnect to the
database--that is the purpose right?

DataSets are not designed for "tons of data". That's what back ends like
SQL Server are for. Applications should generally be designed to move a
minimal amount of data to the client at a time. Otherwise, as you imply,
you use up a lot of query time and marshaling overhead and client resources.

What do you do if User A enters a lot of stuff and then User B does two...
both try to update the dataset to the database and one gets failures--does
that mean I tell him... sorry all your work for the last 30minutes couldn't
be done and dump it?

That is the essence of optimistic concurrency handling, yes, and optimistic
concurrency is at the heart of ADO.NET's design. In most real-world
application scenarios this isn't nearly the problem you'd think it would be.
In the relatively infrequent case where 2 or more users would actually
compete for the same record(s) on a regular basis you may have to rethink
the design or do some work-arounds, but it's really fairly rare in my
experience that users actually get disappointed. First come, first served
is not that bad of a rule.

Pessimistic locking / concurrency requires static connections and static
locks, which eats up server resources quickly.

I guess I just don't get it.. Seems like a whole lot more work than
benefit.

Compared to what? Might be helpful to know what environment you're
accustomed to and how you're used to working with back ends.

I have seen a few instances where I could see the dataset being
useful--like getting a bunch of data to just display and sort etc. But when
it comes to adding data etc. Seems teh direct approach with sqlcommands and
stored procs is more sensible.

Often this is true. Particularly for ASP.NET applications.

Then do you just create a dataset for the whole project and use the same one
for each form--is it globally available, or is the xsd file just a spec that
I use to create a new one in each form as needed?

Usually it works out to something more like a dataset for each use case,
which often corresponds to a particular application window.

Am I totally lost here?

No, just overwhelmed, and you're not unusual ;-)

Any ideas would be appreciated. As you can see I know enough to be
dangerous but still fail to get the big picture and think that it all has to
be easier than what I can see and that also these GUI items in the IDE like
the Server Explorer have to make life easier... But I honestly haven't been
using it so far for my connections--just code--because I know what that does
and how to allow the user to change it.

I find that dragging connections into the UI, using wizards, etc., tends to
produce inefficient, even ugly code, and I figure that if I have to step
through it with the debugger I might as well have written it. It's a good
learning experience anyway.

I reached this conclusion somewhere around 1995 and so didn't even really
try to use these tools in VS.NET. And from what I've heard in this forum
and elsewhere, that hasn't been a bad choice. If you want something done
right ...

--Bob

 

[SStory]

hmmm...

I sort of come from your philosophy... was just afraid maybe there was an
easier way with the wizards and connections things. I come from Visual
Basic background since about 1993... Have done some C windows
programming--yuk.

I was used to getting ADO and recordset and doing things that way
occasionaly using bound controls--more times than not just coding it all.

I have Beginning VB.NET and Professional VB.NET by Wrox, do you have any
other suggestions for a book or resource that would give an excellent
example of building a basic client server database app with .NET?

I am not dealing in n-tier with my vb programming... Just apps for 10-20
users.

I use SQL Server or MSDE for now.

Thanks for "taking a stab at it". Any more opinions or advice is welcome.

Shane

 

[Bob Grommes]

Shane,

Truth be told, I was not really very happy with any of the books I pursued
about .NET, other than a couple of the very introductory language texts,
like Gunnerson's volume on C#, and a stand-out title dealing with COM
Interop; and most of my current efforts are tied up in building n-tier
ASP.NET apps in C#. So I can't make any enthusiastic recommendations for
books that cover your needs.

The way I approached learning DataSets was to write a table wrapper class
that relies on DataSets / DataTables under the hood. Sort of my concept of
how I wished typed DataSets had been implemented. Then I used this in a few
small applications to shake it down. It was a good learning experience, and
left me with an API on top of ADO.NET that works a little more to my liking.
I wish I had an excuse to do a significant WinForms app where I could really
develop the concept some more, but in the ASP.NET world we make much more
predominant use of DataReaders.

--Bob