Karen Yes the small table of records is updating the much larger table. I expect the more records I process the longer the time it will take but why the drastic increase of seconds per record? Thanks Angelo
From: [email protected] To: [email protected] Subject: [RBASE-L] - Re: Declare cursor timing. Date: Sun, 27 Apr 2014 12:41:01 -0500 I generally agree with what you wrote; however, there is not enough information to get an idea on how the entire process is structured. If the full code for the relevant portions of the process is posted, we could probably figure out where the problem is.I have used cursors in the past to do this type of upgrades but recently I have replaced this approach with a single multi-table UPDATE statement; the code is much easier to maintain. Javier, Javier Valencia, PEO: 913-829-0888H: 913-397-9605C: 913-915-3137 From: [email protected] [mailto:[email protected]] On Behalf Of Karen Tellef Sent: Sunday, April 27, 2014 11:17 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Declare cursor timing. But no, Dennis I can't see that being the problem. If I understand his email, the customer order table is the one he's updating and it has 40K rows. He is setting a cursor through a smaller table. If that smaller table has 1 row it's fast, and gets incrementally slower as he cursors through each row. Now yes, the cursor itself takes some time to "open" the recordset, but his example shows a marked difference between 1 row in the table and 30 rows. But the number of rows in customer order table itself isn't changing. Again, that's my understanding of the OP Karen -----Original Message----- From: Dennis McGrath <[email protected]> To: RBASE-L Mailing List <[email protected]> Sent: Sat, Apr 26, 2014 7:59 pm Subject: [RBASE-L] - RE: Declare cursor timing.Is the column receipt indexd?If not, that is the reason for your problem. Dennis McGrathSoftware DeveloperQMI Security Solutions1661 Glenlake AveItasca IL [email protected]: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Saturday, April 26, 2014 4:03 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Declare cursor timing. Dennis The update statement is Update ctrectyd set canceled = .startdat where receipt eq .vrecnumb Thanks AngeloFrom: [email protected] To: [email protected] Date: Fri, 25 Apr 2014 10:49:53 -0500 Subject: [RBASE-L] - RE: Declare cursor timing.Angelo Show us the update command. Dennis McGrathSoftware DeveloperQMI Security Solutions1661 Glenlake AveItasca IL [email protected]: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, April 25, 2014 9:34 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Declare cursor timing. I have an issue on timing. I have two tables, one holds daily transactions and the second holds customer orders. The daily transaction table could hold from 10 to 500 records. The customer order table holds approx. 40,000 records. I am just reading a daily transaction, looking it up by order number and updating the processed date I the customer Order table. In testing I found the following results: If I key an update it is complete in just a second. If the daiily table has 5 records it takes approx. 4 1/2 seconds per record to process. 5 records take 4.5 seconds per record, 10 records take 8 seconds per record, 20 records take 15 seconds per record, 30 records take 24 seconds per record. Why the increment in processing time, any suggestions? If I key an update
