DataAdapter.Update speed problems

use the .getchanges method to get only the changed records before run .update method.

Good suggestion - I'll try it, but probably not until tomorrow (just didn't want you to think I'd abandoned my post). Thanks.

I'm changing every record. .getchanges() would only succeed in using twice the memory.

"I would probably perform much faster (and take advantage of the indexes) if you issued the update statement directly to the database through a connection object. "

I agree. As noted in my original my original post, I might even expect to go from 10 minutes to 15 seconds! So much for my middle tier.

*flame* .net is ridiculous: attempts to hide the database from the erstwhile application developer, but can't take advantage of indices? This seems pretty basic. Grrr.

<MyOpinion>
I do not permit any of my developers to utilize the dataadapter or dataset in this manner.  It smacks too much of RDO bound objects, databinding, slow applications, and untraceable bugs.
</MyOpinion>

No disagreement as far as the slow applications argument goes - it certainly is.

It annoys me that in many situations, VB is to be relegated to doing nothing more than assembling SQL queries, using mind-numbing combinations of stringbuilder.appends() and if-thens/select cases. So much for "hiding" the database structure from the business logic.

<MyOpinion>
I have never been in favor of hiding anything from the developer.
</MyOpinion>

use the adapter.update method is the slowest way to update database. If you update lots of records, and speed is an issue, you better use command object to issue sql statement, or even think about use stored procedure if the speed is still an issue.

"So much for "hiding" the database structure from the business logic."

Note: business object <> developer.

Objects whose responsibility it is to apply the business logic of the application should not be required to have knowledge of the underlying database structure. They shouldn't even care, necessarily, that a database exists. A separate set of objects, who can access the database and present the information found therein in a consistent manner, should have sole responsibility for communicating with those objects responsible for the business logic. Were this not the case, every component of the system would have to be rewritten whenever the database changed! I don't make this stuff up - this is standard n-tier development.

<SadRealization>
Initially, it seemed to me that the .Net structure had made significant strides in enabling this type of application development. Unfortunately, the more I learn, the less I find it to be the case and the more I'm forced to employ the same sorry workarounds I'd hoped to avoid.
</SadRealization>

<Acknowledgement>
Though it did not solve my problem, your observation as to why the .Update method was so slow did, at least, enlighten me as to why it might not be solvable. Thus, I accept it as the answer.
</Acknowledgement>

GoodJun:
See https://www.experts-exchange.com/questions/20565249/Points-for-GoodJun.html

Thanks for your help

thanks for the points

n-tier development:
the workaround we have had to use involves creating business logic objects that communicate with database api objects (objects that have the database logic, and yes, sql written in them).  

We try to use the same set of database api objects for each program, so when the database changes, we rewrite the database api's and copy them to all of the production apps.  

However, this is lett than perfect... I feel you pain.