Newbie Data Access Question--in VB

[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

 

[Armin Zingler]

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

I read your whole post and I came to the conclusion that it's all about
ADO.NET. As the answers are not specific to VB.NET, you should please turn
the ADO.NET group microsoft.public.dotnet.framework.adonet

 

[Herfried K. Wagner [MVP]]

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...

Of you don't get an answer here, you may want to ask these questions in
the ADO.NET group:

<
Web interface:

<http://msdn.microsoft.com/newsgroup...roup=microsoft.public.dotnet.framework.adonet>

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>

<http://www.plig.net/nnq/nquote.html>

 

[Cor]

Hi Armin,

I did read it also and I thought, I am curious what the vb.language group
has for approach on those things.

But my hope is evaporated.

;-(

Cor

 

[SStory]

ok. I will post there. Sorry for offending. Sometimes these technologies
overlap and it isn't easy to know where to ask the question I guess. Just
need answers.

I will try there.

Thanks,

Shane

 

[One Handed Man]

OK here goes.

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

A.)
Then you would use a connecter which points to lets say a central SQL
server.

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.

A.)
You dont have to use datasets, you can simply use tables. After all
when you pull data into a dataset, it simply goes into a table within.
And yes, this is off-line while you are working on the data.

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?

A.)
There are several ways of handling this, however, you need to design
for concurrency conflicts, this is inherent in this kind of scheme

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.

A.)
Some applications do not lend themselves to this kind of data
management. But it is very flexible in other ways.

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?

A.)
You could make it globally available, depending on where you put it
And you could have one.

If your really not comfortable with it then maybe you should use VB6
and ADO rather than VB.NET and ADO.NET.

It will take you some time to get to grips with it but it is actually quite
a nice system once you get around the concept.

OHM

 

[SStory]

Thanks for the reply

What do you mean by a connecter? in the answer to 1.)?

In response to 2 I have just used commands objects for a lot of stuff and
datareaders sometimes.

I was pretty good at VB6 and ADO and have worked with windows programming
for at least 10 years. But I do want to move into VB.NET and have bought
the whole package.. Just having trouble putting what I understand together
in a best practices type scenario.

I have Beginning and Professional VB.NET books from WROX and a great ASP.NET
book and Database Programming with Visual Basic .NET by Thomsen--which is
full of information but still lacking in explaining what I am needing to
know. If you know of any links or other books or resources that would help
me grasp the overall concept enough to know the best ways of programming it
I would appreciate it.

I love the inheritance of VB.NET and many other features. don't like
redistributing the huge runtime, but...that's life. I guess simple apps
should still be written in VB 5 or 6.

Bottom line... If you were writing an app that would have 10 to 15 users and
a MSDE with VB.NET where there won't be very many chances of collisions,
would you do it using datasets and ado.net or would you use datareader and
sqlcommand objects or would you use interop and ADO?

Thanks,

Shane

 

[One Handed Man]

I love the inheritance of VB.NET and many other features. don't like

redistributing the huge runtime, but...that's life. I guess simple
apps should still be written in VB 5 or 6.

Bottom line... If you were writing an app that would have 10 to 15
users and a MSDE with VB.NET where there won't be very many chances
of collisions, would you do it using datasets and ado.net or would
you use datareader and sqlcommand objects or would you use interop
and ADO?

In short, as you know, when you design any system you need it to be robust.
so if you have a remote chance of a save conflict ( going back to my domino
days now)
then you need to have a strategy for dealing with this. To be honest, I
think
in a situation where people working actively on a live database concurrently
and
need record locking, then you probably dont want to use ADO.NET in my
opinion

However, having said that I beleive there are strategies for this out there
which have
been spoken of here and there. But I have not seen them.

I dont think particularly helps you, but at least its another view. As
previously stated
the adonet newgroup is a better place to put this question, but I dont think
you will
get a definitive answer because Ive seen it come up a number of times with
no great
replies.

Regards OHM

 

[SStory]

yeah... Thanks.

Just seems to me that ADO.NET is worthless in that case if you can't have an
app with multiple users access a database--this is the basic purpose of most
apps out there. I sometimes wonder if ADO.NET is a cause without a purpose.
I see some good points but lots of bad ones for sure....

Maybe if the real reason for disconnected datasets is to free up connections
for licensing issues, it might be better to just use MYSql and the .net data
provider for it since it is free and licenses are not an issue.

Thanks again,

Shane

 

[Tom Leylan]

Just seems to me that ADO.NET is worthless in that case if you can't have an
app with multiple users access a database--this is the basic purpose of most
apps out there. I sometimes wonder if ADO.NET is a cause without a purpose.
I see some good points but lots of bad ones for sure....

Maybe if the real reason for disconnected datasets is to free up connections
for licensing issues, it might be better to just use MYSql and the .net data
provider for it since it is free and licenses are not an issue.

What y'all talking about? Just as a matter of course, when I don't
understand something I like to "pause" and figure "well maybe the people who
spent millions implementing this might have a clue."

What was your question again because "worthless" is probably not the answer
and as your reasoning illustrates if the "real reason" was freeing up
connections for licensing issues it wouldn't make much sense... ergo, that
isn't the "real reason" right?

I don't claim to know all the answers but let's start with maybe MS isn't
stupid and work from there

Tom

 

[Ron Allen]

Shane,
I'd suggest getting a copy of "ADO.NET Core Reference" by David Sceppa.
There are a lot of examples in both C# and VB.NET along with some utilities.
David also explains the concepts clearly, in my opinion anyway.

Ron Allen

 

[SStory]

Interesting ideas, however from experience I have seen MS shove their
philosophies down people's throat time and time again.
Not always the best ways to go.... just they are the best marketing machine
around.

I can see in the large corporate setup with tons of users, and businesses
talking to one another through XML and all... just seems that ADO.NET is a
real pain for simple client server apps on the smaller scale 10-20 users and
a database. That's all.

I never said MS is stupid. They are geniouses at taking other peoples ideas,
buying them out marketing the heck out of it and convincing folks to "be
assimulated" as the BORG would say.

Since .NET is a Billion$ project I am sure they thought a lot about it...
however it seems there are some very basic things that they should have
thought more on....

Like making simple Datagrid.... Sort of a pain to customize it... Making
Datareader controls for the IDE incase you didn't want to use datasets for
your project.. It's just that having written 30-50,000 lines of code in
Visual Basic (previous versions in the last couple of years and more before
that, it so far has seemed to take a lot more work to do the same things as
before and be a lot more complicated... although there are some neat new
features that I love... All the OO things made available finally are cool.

Just seems to me that we are 2 versions away from a really nice product that
is RAD instead of RAD--(minus minus)
I guess once I build all my own functions and class libraries to wrap a lot
of this required code writing it will be better.

I am not anti Microsoft but am not afraid to think outside the box either.

Just my 2 cents worth.

Shane

 

[SStory]

OK Thanks Ron.

Shane,
I'd suggest getting a copy of "ADO.NET Core Reference" by David Sceppa.
There are a lot of examples in both C# and VB.NET along with some utilities.
David also explains the concepts clearly, in my opinion anyway.

Ron Allen