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.

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" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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.
>
>
>

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-(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> 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,

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" <(E-Mail Removed)> schreef in bericht
news:%(E-Mail Removed)...
> 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] 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" <(E-Mail Removed)> schreef in bericht
>news:%(E-Mail Removed)...
>
>
>>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

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" <(E-Mail Removed)> wrote in message
news:Cwhcg.51331$(E-Mail Removed)...
> 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" <(E-Mail Removed)> schreef in bericht
>>news:%(E-Mail Removed)...
>>
>>>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

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-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:Cwhcg.51331$(E-Mail Removed)...
>> 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" <(E-Mail Removed)> schreef in bericht
>>>news:%(E-Mail Removed)...
>>>
>>>>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
>
>