What do I get for all this compexity??

[RichG]

Does anyone remember this:
Set datapath to "c:\somewhe re"
dNetUse "SomeTable"
do some db work

I asked the question a couple of days ago about how to attach a recordset or
some form of data to a datagrid. I was using DAO. The lack of responses
seemed to indicate that the question was out of the range of an answer. So I
started looking around to find out what does this datagrid want that the
datagrid in VB5 did not need. It looked like I need to make the leap from
DAO to ADO.NET in order to get a datagrid to work.
So....after much studying I decided to just use the dataform wizard to build
me a connection and populate a datagrid. Then I assumed (bad assumption) I
could just put the parameters into variables and use this dataform for any
table to do a quick view/edit. There are OVER 50 LINES OF CODE in the data
form just to hookup and tell the grid what to show, and it appears that I
cannot make it a generic form.
Tell me is ADO.NET 50 times better than xBase or 20 times better than DAO or
are we being corralled into an increasingly complex program model just for
the sake of "technology marching on".
This is ridiculous!!!!! !!!!!!!!!!!!!!!
And I still don't know how to hook up a user selectable table to a datagrid
using ADO.NET
I don't care if it's a disconnected paradigm. All my apps are small, less
than 10 users. I don't write code for General Motors or CocaCola.
Can anyone point me to a code snipit to do this in ADO.NET in less than 10
lines of code?
Totally Frustrated

[Kevin Spencer]

> This is ridiculous!!!!! !!!!!!!!!!!!!!!

And I still don't know how to hook up a user selectable table to a
datagrid
using ADO.NET
I don't care if it's a disconnected paradigm. All my apps are small, less
than 10 users. I don't write code for General Motors or CocaCola.
Can anyone point me to a code snipit to do this in ADO.NET in less than 10
lines of code?
Once upon a time, all computers were disconnected, and every computer could
only perform precisely one thing at a time. Only one user could use it at a
time, and it could only run one program at a time. At the time, this was
acceptable because there was nothing better.

Time passed, and computer operating systems were invented that could do more
than one thing at a time, and support more than one user. Then came
networking, which allowed computers to talk to each other, share
information, and send commands to one another. This made programming a good
bit more complicated.

Once aupon a time, databases were little more than flat files of delimited
data, which supported only one person accessing the data at a time, and that
person had to be sitting at the machine on which those files resided. With
the advent of multi-tasking operating systems which supported multiple
users, and networking, which allowed data to be shared over networks,
databases evolved as well. Database servers were invented, the SQL language,
which provided a common language to talk to any database, was created, and
as time passed, databases began to be able to do more and more.

This opened up a whole can of worms, as people would do things to other
people and their computers without the permission of the other people.
Security began to become a high priority. As each new capability was added
to hardware, software, and databases, the complexity of these things grew
with it.

Various tools and technologies evolved, in a futile attempt to make complex
systems simpler to work with. I say "futile" because, as the tools enabled
people to do more, the demands for even greater capabilities grew with the
ability. In much the same way that so many "labor-saving devices" of man's
making have never seemed to enable man to work less, so it was with computer
technology.

This is exacerbated by Moore's Law, which operates with a vengeance in the
world of computing.

So, you have 2 choices: You can do the Amish thing, separate from society
and pick a comfortable level of technology to live with for the rest of your
days, as far as programming is concerned, make it a hobby, and be a user in
your professional life. Hire a professional to write your software for you.
Or you can keep up, which is admittedly not an easy thing to do.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.

"RichG" <Ri***@discussi ons.microsoft.c om> wrote in message
news:78******** *************** ***********@mic rosoft.com... Does anyone remember this:
Set datapath to "c:\somewhe re"
dNetUse "SomeTable"
do some db work

I asked the question a couple of days ago about how to attach a recordset
or
some form of data to a datagrid. I was using DAO. The lack of responses
seemed to indicate that the question was out of the range of an answer.
So I
started looking around to find out what does this datagrid want that the
datagrid in VB5 did not need. It looked like I need to make the leap from
DAO to ADO.NET in order to get a datagrid to work.
So....after much studying I decided to just use the dataform wizard to
build
me a connection and populate a datagrid. Then I assumed (bad assumption)
I
could just put the parameters into variables and use this dataform for any
table to do a quick view/edit. There are OVER 50 LINES OF CODE in the
data
form just to hookup and tell the grid what to show, and it appears that I
cannot make it a generic form.
Tell me is ADO.NET 50 times better than xBase or 20 times better than DAO
or
are we being corralled into an increasingly complex program model just for
the sake of "technology marching on".
This is ridiculous!!!!! !!!!!!!!!!!!!!!
And I still don't know how to hook up a user selectable table to a
datagrid
using ADO.NET
I don't care if it's a disconnected paradigm. All my apps are small, less
than 10 users. I don't write code for General Motors or CocaCola.
Can anyone point me to a code snipit to do this in ADO.NET in less than 10
lines of code?
Totally Frustrated

[Patrice]

I remember these times but you couldn't use SQL to query the DB and
accessing a foreign DB format was an unreachable dream...

As far as the current problem, my personal preference is to not use wizard.
Once you have written (or borrowed) your own data access layer you don't
have to code again and again what you have already in your arsenal.

You could start by what you would like to write an implement the details.
Here I'm not sure why you can't get generic binding.. My guess would be that
this is because you are using at this time the designers ?

--

"RichG" <Ri***@discussi ons.microsoft.c om> a écrit dans le message de news:
78************* *************** **...icrosof t.com...

Does anyone remember this:
Set datapath to "c:\somewhe re"
dNetUse "SomeTable"
do some db work

I asked the question a couple of days ago about how to attach a recordset
or
some form of data to a datagrid. I was using DAO. The lack of responses
seemed to indicate that the question was out of the range of an answer.
So I
started looking around to find out what does this datagrid want that the
datagrid in VB5 did not need. It looked like I need to make the leap from
DAO to ADO.NET in order to get a datagrid to work.
So....after much studying I decided to just use the dataform wizard to
build
me a connection and populate a datagrid. Then I assumed (bad assumption)
I
could just put the parameters into variables and use this dataform for any
table to do a quick view/edit. There are OVER 50 LINES OF CODE in the
data
form just to hookup and tell the grid what to show, and it appears that I
cannot make it a generic form.
Tell me is ADO.NET 50 times better than xBase or 20 times better than DAO
or
are we being corralled into an increasingly complex program model just for
the sake of "technology marching on".
This is ridiculous!!!!! !!!!!!!!!!!!!!!
And I still don't know how to hook up a user selectable table to a
datagrid
using ADO.NET
I don't care if it's a disconnected paradigm. All my apps are small, less
than 10 users. I don't write code for General Motors or CocaCola.
Can anyone point me to a code snipit to do this in ADO.NET in less than 10
lines of code?
Totally Frustrated

[Rob R. Ainscough]

Don't feel too frustrated, at lot of "profession al" developers are in or
have been thru the same frustration.

I would have preferred Microsoft "extended" the platform rather than
re-invent, but they didn't so the long task on learning started. By the
time I'm finally comfortable with the platform (not there yet but getting
closer), I'm sure I'll be back in the same boat -- as MS re-invent again --
so much for "re-use".

What "keeping up" has done for me is basically reduced my quality of life as
I've had to spend all my evenings and weekends reading volumes of material
and performing trial & error coding and putting the pieces together -- then
during my real day job I have to put the code to real world use with real
world deadlines and try to generate real world revenue (I don't work for a
large company either).

Stick with it and you'll eventually come out the otherside -- just in time
to start the process all over again for the next "keep up" technology.

What I'd recommend, is try to build up that retirement fund and plan your
exit strategy just before another vicious cycle begins. This is my final go
around -- the next re-invent and I plan to be saying "...and now for
something completely different...". I've been coding since 16 and I'm now
41 -- I'm at the point where I have other things I'd rather "keep up" with
and let the younger generation of developers go thru the ringer.

Kevin -- computers (pre PC) where designed from scratch to process large
volumes of data (aka a database) and handle many users at the same time --
your analogy is just not correct. It is also no secret that .NET is just a
wrapper around existing code with some tweaks added. .NET is NOT the only
logical way for MS to proceed with a development platform.

Cheers, Rob.
"RichG" <Ri***@discussi ons.microsoft.c om> wrote in message
news:78******** *************** ***********@mic rosoft.com...

Does anyone remember this:
Set datapath to "c:\somewhe re"
dNetUse "SomeTable"
do some db work

I asked the question a couple of days ago about how to attach a recordset
or
some form of data to a datagrid. I was using DAO. The lack of responses
seemed to indicate that the question was out of the range of an answer.
So I
started looking around to find out what does this datagrid want that the
datagrid in VB5 did not need. It looked like I need to make the leap from
DAO to ADO.NET in order to get a datagrid to work.
So....after much studying I decided to just use the dataform wizard to
build
me a connection and populate a datagrid. Then I assumed (bad assumption)
I
could just put the parameters into variables and use this dataform for any
table to do a quick view/edit. There are OVER 50 LINES OF CODE in the
data
form just to hookup and tell the grid what to show, and it appears that I
cannot make it a generic form.
Tell me is ADO.NET 50 times better than xBase or 20 times better than DAO
or
are we being corralled into an increasingly complex program model just for
the sake of "technology marching on".
This is ridiculous!!!!! !!!!!!!!!!!!!!!
And I still don't know how to hook up a user selectable table to a
datagrid
using ADO.NET
I don't care if it's a disconnected paradigm. All my apps are small, less
than 10 users. I don't write code for General Motors or CocaCola.
Can anyone point me to a code snipit to do this in ADO.NET in less than 10
lines of code?
Totally Frustrated

[Kevin Spencer]

Hi Rob,

Kevin -- computers (pre PC) where designed from scratch to process large
volumes of data (aka a database) and handle many users at the same time --
your analogy is just not correct. It is also no secret that .NET is just
a wrapper around existing code with some tweaks added. .NET is NOT the
only logical way for MS to proceed with a development platform.
I'm not sure what it is you're disagreeing with here. From the sound of your
message, I would have guessed that you agreed with me. If you think that
"computers (pre PC) where designed ... to handle many users at the same
time," well, you're just picking your favorite point to start counting at.
The first computers were certainly not designed to either work with
databases, nor to handle more than one user at a time. As for .Net being
"just a wrapper around existing code with some tweaks added," you might as
well say the same for Assembler, which is "just a wrapper around machine
language," and C, which is "just a wrapper around Assembler."

In fact, you might as well say that Calculus is a wrapper around
Trigonometry, which is a wrapper around Geometry, which is a wrapper around
algebra, which is a wrapper around arithmetic, which is a wrapper around
counting. Both are true, and both are irrelevant. As my Uncle Chuteny sez,
"Big things are made up of lots of little things," and its correlary:
"Complex things are made up of lots of simple things."

Your message indicates that you have to work very hard to keep up. So do I.
I put in anywhere from 60 - 80 hours per week at my chosen profession. And I
wouldn't have it any other way. Do I wish I had more free time? Sure. But I
wish I had more time - period. I have to admit, I haven't been programming
since I was 16, but I am 50 years old, been at it for quite a few years, and
dread the idea of having to retire some day.

--

Kevin Spencer
Microsoft MVP
Professional Numbskull

Hard work is a medication for which
there is no placebo.
"Rob R. Ainscough" <ro*****@pacbel l.net> wrote in message
news:eO******** ********@TK2MSF TNGP05.phx.gbl. .. Don't feel too frustrated, at lot of "profession al" developers are in or
have been thru the same frustration.

I would have preferred Microsoft "extended" the platform rather than
re-invent, but they didn't so the long task on learning started. By the
time I'm finally comfortable with the platform (not there yet but getting
closer), I'm sure I'll be back in the same boat -- as MS re-invent
again -- so much for "re-use".

What "keeping up" has done for me is basically reduced my quality of life
as I've had to spend all my evenings and weekends reading volumes of
material and performing trial & error coding and putting the pieces
together -- then during my real day job I have to put the code to real
world use with real world deadlines and try to generate real world revenue
(I don't work for a large company either).

Stick with it and you'll eventually come out the otherside -- just in time
to start the process all over again for the next "keep up" technology.

What I'd recommend, is try to build up that retirement fund and plan your
exit strategy just before another vicious cycle begins. This is my final
go around -- the next re-invent and I plan to be saying "...and now for
something completely different...". I've been coding since 16 and I'm now
41 -- I'm at the point where I have other things I'd rather "keep up" with
and let the younger generation of developers go thru the ringer.

Kevin -- computers (pre PC) where designed from scratch to process large
volumes of data (aka a database) and handle many users at the same time --
your analogy is just not correct. It is also no secret that .NET is just
a wrapper around existing code with some tweaks added. .NET is NOT the
only logical way for MS to proceed with a development platform.

Cheers, Rob.
"RichG" <Ri***@discussi ons.microsoft.c om> wrote in message
news:78******** *************** ***********@mic rosoft.com...

Does anyone remember this:
Set datapath to "c:\somewhe re"
dNetUse "SomeTable"
do some db work

I asked the question a couple of days ago about how to attach a recordset
or
some form of data to a datagrid. I was using DAO. The lack of responses
seemed to indicate that the question was out of the range of an answer.
So I
started looking around to find out what does this datagrid want that the
datagrid in VB5 did not need. It looked like I need to make the leap
from
DAO to ADO.NET in order to get a datagrid to work.
So....after much studying I decided to just use the dataform wizard to
build
me a connection and populate a datagrid. Then I assumed (bad assumption)
I
could just put the parameters into variables and use this dataform for
any
table to do a quick view/edit. There are OVER 50 LINES OF CODE in the
data
form just to hookup and tell the grid what to show, and it appears that I
cannot make it a generic form.
Tell me is ADO.NET 50 times better than xBase or 20 times better than DAO
or
are we being corralled into an increasingly complex program model just
for
the sake of "technology marching on".
This is ridiculous!!!!! !!!!!!!!!!!!!!!
And I still don't know how to hook up a user selectable table to a
datagrid
using ADO.NET
I don't care if it's a disconnected paradigm. All my apps are small,
less
than 10 users. I don't write code for General Motors or CocaCola.
Can anyone point me to a code snipit to do this in ADO.NET in less than
10
lines of code?
Totally Frustrated

[RichG]

Thanks all for the consolation.
I try not to chase the edge because of the cost in time and resources.
Resources being mental health and “a life�. That's why I'm coming into this
from DAO and VB5.
I've made my bundle and blown my bundle a couple of times now, but I've come
to realize that work is good and it does keep you healthy, if put in its
proper place.
SQL, as it was called when IBM invented it back in the late 60's was a great
thing. It does allow for multiple data formats to be accessed for one
source. That is good. I don't know when somebody thought it was cute to try
and pronounce SQL and then even try to spell the pronunciation of an acronym
with SEEQUEL. But that's how things get weird.
I would think that extending a technology that seems to work rather than
starting over, and using the same terms but redefining them, and creating new
terms from combinations of old terms that have nothing to do with either term
would be better. Was that last sentence confusing? Not nearly as much as
the morons that overload terms at Microsoft.
I have several private problems with the way technology is moving, but I'm
not the referee of society.
I'll bite the bullet and spend a couple of days with ADO.NET and it will
become fairly clear but from what I see so far, it is waaaaay toooo
complicated for what it is supposed to do. When I hire programmers I always
tell them rule number 1:
If an algorithm seems to complicated, it's because it is. Back up, break it
down more and make it simple. There are only 4 rules and that is number one.
So the question is; is all this complexity really necessary? The answer is
no! It was done wrong. But we do not live in a perfect world, so we learn
to make do with what we have, and be happy!

[Rob R. Ainscough]

Rich,

My real contention with Microsoft's path is the redundancy of re-learning
the same concepts over and over only done with a different wrapper -- this
is just not a good use of my life nor my time (especially with tasks that
produce the exact same end result, sometimes faster, sometimes slower).
Maybe Kevin and others enjoy the process of adapting to the latest syntax
thrust on them, but for all intense purposes it is like learning Spanish,
French, German, etc. etc. when all I really need to do is communicate in one
language - extend the language don't re-write it.

Anyway, like I said, this is the last iteration I'm going thru and will move
on to bigger challenges that are truely more thought provoking and
challenging to me -- I for one don't find figuring out how to do the same
tasks the ADO.NET way or the VB.NET or the ASP.NET a real source of
knowledge expansion -- I find it pretty boring and redundant (maybe because
I've had to do it so many times).

BTW, you can go to from VB5 to VB6 without any worries other than updating
your deployment.

Rob.
"RichG" <Ri***@discussi ons.microsoft.c om> wrote in message
news:CC******** *************** ***********@mic rosoft.com...

Thanks all for the consolation.
I try not to chase the edge because of the cost in time and resources.
Resources being mental health and "a life". That's why I'm coming into
this
from DAO and VB5.
I've made my bundle and blown my bundle a couple of times now, but I've
come
to realize that work is good and it does keep you healthy, if put in its
proper place.
SQL, as it was called when IBM invented it back in the late 60's was a
great
thing. It does allow for multiple data formats to be accessed for one
source. That is good. I don't know when somebody thought it was cute to
try
and pronounce SQL and then even try to spell the pronunciation of an
acronym
with SEEQUEL. But that's how things get weird.
I would think that extending a technology that seems to work rather than
starting over, and using the same terms but redefining them, and creating
new
terms from combinations of old terms that have nothing to do with either
term
would be better. Was that last sentence confusing? Not nearly as much as
the morons that overload terms at Microsoft.
I have several private problems with the way technology is moving, but I'm
not the referee of society.
I'll bite the bullet and spend a couple of days with ADO.NET and it will
become fairly clear but from what I see so far, it is waaaaay toooo
complicated for what it is supposed to do. When I hire programmers I
always
tell them rule number 1:
If an algorithm seems to complicated, it's because it is. Back up, break
it
down more and make it simple. There are only 4 rules and that is number
one.
So the question is; is all this complexity really necessary? The answer
is
no! It was done wrong. But we do not live in a perfect world, so we
learn
to make do with what we have, and be happy!