Re: Batchupdates performance
- From: "Del Murray" <Del.Murray@xxxxxxxxxxxxxx>
- Date: Thu, 3 May 2007 21:20:02 -0500
When you say 35 "new fields" , do you mean you changed the value of 35
existing columns in 500 rows or do you mean you added 35 "new" columns to an
existing row ???
BatchOptimistic updating can be a bit slow but yours sounds very slow. It
may be an Oracle issue .. allocating additional space, poor indexing
schemes. When you do batch optimistic locking, you need an ***primary key***
selected in your dataset. That way the DB can go immediately to the proper
row in the phsysical database and update the data. When you dont supply a
unique key (primary index or primary key .. depending on the DB), then the
DB engine must take each record that you have in your data set and read from
one end of the table to the other to determine which row was the row that
you wanted to update. .... Then, he takes the next row in your dataset and
once again, reads from one end of the table to the other to see which row
should receive the updates ...get the picture ???? when you create your
dataset do something like this .. 'select id, name, address, ssn from
tablexxx where name like '%A%'
id (in the select statement) is the primary key defined for the table. By
definition, primary keys are "unique keys".
HTH
Del
.
- Follow-Ups:
- Re: Batchupdates performance
- From: Del Murray
- Re: Batchupdates performance
- References:
- Batchupdates performance
- From: pilmart
- Batchupdates performance
- Prev by Date: Re: Zip the SQL Server database
- Next by Date: Re: Batchupdates performance
- Previous by thread: Batchupdates performance
- Next by thread: Re: Batchupdates performance
- Index(es):
Relevant Pages
|