By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,639 Members | 1,326 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,639 IT Pros & Developers. It's quick & easy.

Update an Access DB using VB.Net

P: n/a
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?

--
|
+-- Julian
|

Mar 28 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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.

Mar 28 '06 #2

P: n/a
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
Mar 28 '06 #3

P: n/a


"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
Mar 28 '06 #4

P: n/a
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

"George" <Ge****@discussions.microsoft.com> schreef in bericht
news:58**********************************@microsof t.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

Mar 29 '06 #5

P: n/a
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.

Mar 29 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.