 |
BorlandTalk.com Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Andrew Guest
|
Posted: Thu Jul 14, 2005 2:08 am Post subject: UpdateBatch - taking a while |
|
|
Hi,
I use UpdateBatch in an attempt to speed up the processing of user interaction and allow a global "do you want to save changes to the database?".
Using the Jet engine for MS-Access databases, I note that the process of updating is not overly fast (eg: 1154 changes take about 3 seconds to update).
i) Is there any way to speed this up?
ii) Is there any way to display a progress bar for the user so that they know roughly how long it still has to go?
I suspect that the answers to both are "NO", but live in hope!
Cheers,
Andrew
|
|
| Back to top |
|
 |
Del M Guest
|
Posted: Thu Jul 14, 2005 12:40 pm Post subject: Re: UpdateBatch - taking a while |
|
|
That's probably not bad for Access. How does the user get 1154 changes into
the system without being asked if the "want to save" ? Maybe if they app
forced them to save more often the time wouldn't seem so long. You can check
the ado recordset to see how many "changed" records are there and force an
update ever 100 or so records. If done inside a transaction, you would have
the opportunity to rollback the whole set ..
|
|
| Back to top |
|
 |
Andrew Guest
|
Posted: Fri Jul 15, 2005 1:30 am Post subject: Re: UpdateBatch - taking a while |
|
|
Thanks.
The user gets that many changes by running an 'autoallocate' feature which allocates people to groups. This may change everyone in one go (or only a few), yet the user needs to be able to accept / reject the proposed solution before being saved to the database.
I'll have to put up with the speed issue, but do you know of any way to display a progress bar during the batch update?
Cheers,
Andrew
"Del M" <Del.Murray (AT) CreditHawk (DOT) Net> wrote
| Quote: | That's probably not bad for Access. How does the user get 1154 changes into
the system without being asked if the "want to save" ? Maybe if they app
forced them to save more often the time wouldn't seem so long. You can check
the ado recordset to see how many "changed" records are there and force an
update ever 100 or so records. If done inside a transaction, you would have
the opportunity to rollback the whole set ..
|
|
|
| Back to top |
|
 |
Del M Guest
|
Posted: Sat Jul 16, 2005 3:45 am Post subject: Re: UpdateBatch - taking a while |
|
|
Not really. That is an old question. You just have to create a "dancing
bear" of some kind. One thing that helps is to set the cursor to a sql hour
glass and then set it back when its done. Another trick would be to walk to
recordset and for each changed record (updates pending) you can to a sql
"insert" via another tAdoDataset. Since these would be going one at a time,
and since control will be returned to you between each update, you could
create a progress bar. If you "disablecontrols" on both datasets before you
start the loop and if your insert uses parameters to pass the data, it might
be faster than actually useing "batch update". Upon completion, you could
cancelupdates in the original dataset and requery to get the new data.
|
|
| Back to top |
|
 |
Andrew Guest
|
Posted: Sat Jul 16, 2005 5:02 am Post subject: Re: UpdateBatch - taking a while |
|
|
Many thanks
"Del M" <Del.Murray (AT) CreditHawk (DOT) Net> wrote
| Quote: | Not really. That is an old question. You just have to create a "dancing
bear" of some kind. One thing that helps is to set the cursor to a sql hour
glass and then set it back when its done. Another trick would be to walk to
recordset and for each changed record (updates pending) you can to a sql
"insert" via another tAdoDataset. Since these would be going one at a time,
and since control will be returned to you between each update, you could
create a progress bar. If you "disablecontrols" on both datasets before you
start the loop and if your insert uses parameters to pass the data, it might
be faster than actually useing "batch update". Upon completion, you could
cancelupdates in the original dataset and requery to get the new data.
|
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|