![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 5 of 5 total |
![]() |
Wed, May 17 2006 8:21 AM | Permanent Link |
Allan brocklehurst | Hi.
Stats D7 v 4.24 C/S application I’m enhancing an application that updates several files with data in “Batch mode”. This will now be done during working hours. Prior to this all “Batch mode” updates were processed overnight. I’m updating the target tables with straight file processing. Currently: The users have only read capabilities on the data. The data is served to them via SQL statements. Because of this “live” data update, I’m concerned that the process will crash if I send in a record that is currently in use. BTW, I have to replace any existing records with a new record. That is deleting all detail records and adding new ones. So what would be the safest solution for this? I was thinking that I set the “request live” to false on the above SQL statements? That’s all I got! Allan |
Wed, May 17 2006 10:05 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Allan
Go for transactions and keep the batch sizes as small as possible so that it doesn't take to long. Roy Lambert |
Wed, May 17 2006 10:19 AM | Permanent Link |
Allan brocklehurst | Roy Lambert wrote:
> Allan > > > Go for transactions and keep the batch sizes as small as possible so that it doesn't take to long. > > Roy Lambert > Roy; Hi and Thanks. I'll do the research and use your suggestion. Allan |
Wed, May 17 2006 4:04 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Allan,
Roy is correct - use small batches of transactions and just update the tables in-place. Because the users can't even edit records, then there won't be any record lock conflicts to deal with. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 18 2006 7:14 AM | Permanent Link |
Allan brocklehurst | Tim Young [Elevate Software] wrote:
> Allan, > > Roy is correct - use small batches of transactions and just update the > tables in-place. Because the users can't even edit records, then there > won't be any record lock conflicts to deal with. > Thanks again Tim and Roy. The record-locking was the rub on this one Allan |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |