Really puzzled (or maybe just totally confused) about VB.NET and ADO.NET

[Sam Malone]

Am I just totally missing something here? I'm just new to VS.NET 2005
(using VB.NET) and ADO.NET.
I get the impression that ADO.NET can't do what I'm used to doing with ADO
(previous ADO withVB6).
I used to bind (let's say a text box) to a field (column) in a recordset and
if I typed a value in that textbox and tabbed out of it, the value in the
database got updated without me having to do anything else.
Now what I see is a terribly convoluted mish-mash of connections, adapters,
datasets that have to be "filled" etc and then there's the data bindings to
get it so you can just "see" what is in your database (excuse me, data
"source") and then after all of that it doesn't even keep up to date (if
something in the underlying database changes) much less update the database
after all. I have to write the code to do that too!!!!
Keep in mind the very first sentence... Am I missing something here?? OMG I
hope I am.

[Scott M.]

ADO.NET is disconnect by nature as opposed to ADO, which usually worked with
the actual data in the database. So, in ADO.NET you work with a copy of the
data, and when you are ready, you update the original data source with your
copy's changes.

This architecture reduces server load and generally improves the
application's response time (if you are smart about how and when you connect
to the data source).
"Sam Malone" <th************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

Am I just totally missing something here? I'm just new to VS.NET 2005
(using VB.NET) and ADO.NET.
I get the impression that ADO.NET can't do what I'm used to doing with ADO
(previous ADO withVB6).
I used to bind (let's say a text box) to a field (column) in a recordset
and if I typed a value in that textbox and tabbed out of it, the value in
the database got updated without me having to do anything else.
Now what I see is a terribly convoluted mish-mash of connections,
adapters, datasets that have to be "filled" etc and then there's the data
bindings to get it so you can just "see" what is in your database (excuse
me, data "source") and then after all of that it doesn't even keep up to
date (if something in the underlying database changes) much less update
the database after all. I have to write the code to do that too!!!!
Keep in mind the very first sentence... Am I missing something here?? OMG
I hope I am.

[Sam Malone]

Cripes. Seems like a MAJOR step backwards to me. People cost way more than
CPU cycles. Oh well, I'm sure my whining won't change M$ attitude. At least
it does show I wasn't as confused as I thought (hoped) I was :-(

"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

ADO.NET is disconnect by nature as opposed to ADO, which usually worked
with the actual data in the database. So, in ADO.NET you work with a copy
of the data, and when you are ready, you update the original data source
with your copy's changes.

This architecture reduces server load and generally improves the
application's response time (if you are smart about how and when you
connect to the data source).
"Sam Malone" <th************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

Am I just totally missing something here? I'm just new to VS.NET 2005
(using VB.NET) and ADO.NET.
I get the impression that ADO.NET can't do what I'm used to doing with
ADO (previous ADO withVB6).
I used to bind (let's say a text box) to a field (column) in a recordset
and if I typed a value in that textbox and tabbed out of it, the value in
the database got updated without me having to do anything else.
Now what I see is a terribly convoluted mish-mash of connections,
adapters, datasets that have to be "filled" etc and then there's the data
bindings to get it so you can just "see" what is in your database (excuse
me, data "source") and then after all of that it doesn't even keep up to
date (if something in the underlying database changes) much less update
the database after all. I have to write the code to do that too!!!!
Keep in mind the very first sentence... Am I missing something here?? OMG
I hope I am.

[Cor Ligthert [MVP]]

Sam,

If you had to think about an uniform method for a

Connected PC
Mobile device
Not connected mobile PDA device
Endless amounts of active webpage's

Have you any idea how to handle that with a connected recordset?

Cor

"Sam Malone" <th************@hotmail.com> schreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl...

Am I just totally missing something here? I'm just new to VS.NET 2005
(using VB.NET) and ADO.NET.
I get the impression that ADO.NET can't do what I'm used to doing with ADO
(previous ADO withVB6).
I used to bind (let's say a text box) to a field (column) in a recordset
and if I typed a value in that textbox and tabbed out of it, the value in
the database got updated without me having to do anything else.
Now what I see is a terribly convoluted mish-mash of connections,
adapters, datasets that have to be "filled" etc and then there's the data
bindings to get it so you can just "see" what is in your database (excuse
me, data "source") and then after all of that it doesn't even keep up to
date (if something in the underlying database changes) much less update
the database after all. I have to write the code to do that too!!!!
Keep in mind the very first sentence... Am I missing something here?? OMG
I hope I am.

[tomb]

Cor Ligthert [MVP] wrote:

Sam,

If you had to think about an uniform method for a

Connected PC
Mobile device
Not connected mobile PDA device
Endless amounts of active webpage's

Have you any idea how to handle that with a connected recordset?

Cor

"Sam Malone" <th************@hotmail.com> schreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl...

Am I just totally missing something here? I'm just new to VS.NET 2005
(using VB.NET) and ADO.NET.
I get the impression that ADO.NET can't do what I'm used to doing with ADO
(previous ADO withVB6).
I used to bind (let's say a text box) to a field (column) in a recordset
and if I typed a value in that textbox and tabbed out of it, the value in
the database got updated without me having to do anything else.
Now what I see is a terribly convoluted mish-mash of connections,
adapters, datasets that have to be "filled" etc and then there's the data
bindings to get it so you can just "see" what is in your database (excuse
me, data "source") and then after all of that it doesn't even keep up to
date (if something in the underlying database changes) much less update
the database after all. I have to write the code to do that too!!!!
Keep in mind the very first sentence... Am I missing something here?? OMG
I hope I am.

I think Sam has an excellent point - as developers we should have a
choice of working in a connected mode or not. In VB 6 we could work
with that recordset object as connected or not. Surely MS could have
given us the option of using ado.net in connected or disconnected mode,
maybe with two different components.

Tom

[Scott M.]

You can work in connected mode in one of two ways:

Read-only, forward-only needs are handled by the ADO.NET DataReader.

If read/write is desired, you can still use the ADO Recordset (if you must),
using COM InterOp.

Give the disconnected paradigm a chance, it is more code, but it results in
MUCH better performance overall.

"tomb" <to**@technetcenter.com> wrote in message
news:Cw*******************@bignews2.bellsouth.net. ..

Cor Ligthert [MVP] wrote:

Sam,

If you had to think about an uniform method for a

Connected PC
Mobile device
Not connected mobile PDA device
Endless amounts of active webpage's

Have you any idea how to handle that with a connected recordset?

Cor

"Sam Malone" <th************@hotmail.com> schreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl.. .

Am I just totally missing something here? I'm just new to VS.NET 2005
(using VB.NET) and ADO.NET.
I get the impression that ADO.NET can't do what I'm used to doing with
ADO (previous ADO withVB6).
I used to bind (let's say a text box) to a field (column) in a recordset
and if I typed a value in that textbox and tabbed out of it, the value in
the database got updated without me having to do anything else.
Now what I see is a terribly convoluted mish-mash of connections,
adapters, datasets that have to be "filled" etc and then there's the data
bindings to get it so you can just "see" what is in your database (excuse
me, data "source") and then after all of that it doesn't even keep up to
date (if something in the underlying database changes) much less update
the database after all. I have to write the code to do that too!!!!
Keep in mind the very first sentence... Am I missing something here?? OMG
I hope I am.

I think Sam has an excellent point - as developers we should have a choice
of working in a connected mode or not. In VB 6 we could work with that
recordset object as connected or not. Surely MS could have given us the
option of using ado.net in connected or disconnected mode, maybe with two
different components.

Tom

[Sam Malone]

Thanks. I've been spending the weekend (it's a three day weekend here in
Canada) reading about it and yes I'm going to "give it a chance".
"Scott M." <s-***@nospam.nospam> wrote in message
news:eo**************@TK2MSFTNGP05.phx.gbl...

You can work in connected mode in one of two ways:

Read-only, forward-only needs are handled by the ADO.NET DataReader.

If read/write is desired, you can still use the ADO Recordset (if you
must), using COM InterOp.

Give the disconnected paradigm a chance, it is more code, but it results
in MUCH better performance overall.

"tomb" <to**@technetcenter.com> wrote in message
news:Cw*******************@bignews2.bellsouth.net. ..

Cor Ligthert [MVP] wrote:

Sam,

If you had to think about an uniform method for a

Connected PC
Mobile device
Not connected mobile PDA device
Endless amounts of active webpage's

Have you any idea how to handle that with a connected recordset?

Cor

"Sam Malone" <th************@hotmail.com> schreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl. ..

Am I just totally missing something here? I'm just new to VS.NET 2005
(using VB.NET) and ADO.NET.
I get the impression that ADO.NET can't do what I'm used to doing with
ADO (previous ADO withVB6).
I used to bind (let's say a text box) to a field (column) in a recordset
and if I typed a value in that textbox and tabbed out of it, the value
in the database got updated without me having to do anything else.
Now what I see is a terribly convoluted mish-mash of connections,
adapters, datasets that have to be "filled" etc and then there's the
data bindings to get it so you can just "see" what is in your database
(excuse me, data "source") and then after all of that it doesn't even
keep up to date (if something in the underlying database changes) much
less update the database after all. I have to write the code to do that
too!!!!
Keep in mind the very first sentence... Am I missing something here??
OMG I hope I am.

I think Sam has an excellent point - as developers we should have a
choice of working in a connected mode or not. In VB 6 we could work with
that recordset object as connected or not. Surely MS could have given us
the option of using ado.net in connected or disconnected mode, maybe with
two different components.

Tom