Home All Groups Group Topic Archive Search About

Update an Access DB using VB.Net

Author
28 Mar 2006 12:44 PM
Julian
I need to update 4 fields of a 20-field table. The table has no primary key.
I need to cycle thru each of the four fields for each record to manipulate
the data before writing it to the DB. In VB6, we used recordsets which were
always connected to the DB, but for some strange reason, MS decided to
implement unattached data objects (DataAdapter & DataSet).

So how can I update my table above?

--
Show quoteHide quote
|
+-- Julian
|

Author
28 Mar 2006 1:00 PM
Cerebrus
Hi,

>> ...but for some strange reason, MS decided to
>> implement unattached data objects (DataAdapter & DataSet).

IMO, this disconnected architecture is one of the best things about
ADO.NET, and it's where it scores highly over traditional ADO.

Calling your DataAdapter.Update() method will update the data from the
Dataset to the Database.

HTH,

Regards,

Cerebrus.
Author
28 Mar 2006 3:21 PM
Cor Ligthert [MVP]
Julian,

I am curious, are you real not able to see the reason from this, beside the
technical problems there are with to many users on a disconnected
databaseserver.

> but for some strange reason, MS decided to implement unattached data
> objects (DataAdapter & DataSet).

Cor
Author
28 Mar 2006 4:13 PM
George
Show quote Hide quote
"Cor Ligthert [MVP]" wrote:

> Julian,
>
> I am curious, are you real not able to see the reason from this, beside the
> technical problems there are with to many users on a disconnected
> databaseserver.
>
> > but for some strange reason, MS decided to implement unattached data
> > objects (DataAdapter & DataSet).
>
> Cor
>
>
>

I know I cannot see the reason behind this.

Maybe it makes since if you are dealing with server apps.  But in my case, I
write mainly pc apps where the database resides on the pc.  In VB6 we just
used the recordset to add, update and delete.  It was straight to the point.

George
Author
29 Mar 2006 5:14 AM
Cor Ligthert [MVP]
George,

In a single user situation it is not important if you are connected or not
connected. In some cases will the use of pessimistic concurrency work easier
than optimistic concurrency. This is direct connected to the fact if you are
online. Pessimistic concurrency in a disconnected situatie will need a lot
of extra database programming or will give deadlocks.

Just my thouhgt,

Cor

Show quoteHide quote
"George" <Geo***@discussions.microsoft.com> schreef in bericht
news:588769E2-98B1-4D30-A940-0EAB9D51AE79@microsoft.com...
>
>
> "Cor Ligthert [MVP]" wrote:
>
>> Julian,
>>
>> I am curious, are you real not able to see the reason from this, beside
>> the
>> technical problems there are with to many users on a disconnected
>> databaseserver.
>>
>> > but for some strange reason, MS decided to implement unattached data
>> > objects (DataAdapter & DataSet).
>>
>> Cor
>>
>>
>>
>
> I know I cannot see the reason behind this.
>
> Maybe it makes since if you are dealing with server apps.  But in my case,
> I
> write mainly pc apps where the database resides on the pc.  In VB6 we just
> used the recordset to add, update and delete.  It was straight to the
> point.
>
> George
>
>
Author
29 Mar 2006 6:39 AM
Cerebrus
Hi George,

Databases are at their best, when they can service more and more
clients. A single-client database isn't what is used in most
corporations these days, not would it be practical.

It's perfectly cool that you need to write only single-user apps, but I
think you would acknowledge that this is not a common scenario.
Therefore Microsoft's shift towards a disconnected database access has
greatly enhanced the potential of various Client-Server applications.

Previous versions of ADO provided continuously connected data by
default, and the connection was kept open till the data was required,
or for the entire life of the application. When such databases serve
more and more clients, there was a definite decrease in the Performance
of the application, and consequently in the potential scalability.

The advantage with ADO.NET is that the connection is left open only
long enough to execute the appropriate command (SELECT, UPDATE or
whatever). So, connections are kept open for the minimum possible time,
and least system resources are used.

Try as I might, I can't find a fault with that !

Regards,

Cerebrus.