Further to all the good suggestions in this thread...
I just reviewed some code which builds a matrix, summing totals for different dates which was too slow. For 100,000 rows it took 8.5 seconds to process.
Building temp tables/views to limit row selection made little difference. But, by just doing calculations outside the While loop reduced the time to 3.5 seconds.
Instead of Where colname = (.vdate + 1), (.vdate + 2), (.vdate + 3) etc., I set the vars outside the loop and the code was colname = .vdate1, .vdate2, .vdate3, etc.
Try and reduce the number of commands in the While loop by building one or more powerful Select command with Union, Join, Having, Group By, etc. In some cases, as mentioned earlier, you can eliminate the entire Declare cursor code.
Dennis
*****
At 03:15 PM 4/27/2014, you wrote:
KarenI 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.
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 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, PE
O: 913-829-0888
H: 913-397-9605
C: 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 McGrath
Software Developer
QMI Security Solutions
1661 Glenlake Ave
Itasca IL 60143
630-980-8461
[email protected]
From: [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
Angelo
From: [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 McGrath
Software Developer
QMI Security Solutions
1661 Glenlake Ave
Itasca IL 60143
630-980-8461
[email protected]
From: [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
Dennis Fleming
IISCO
Phone: 570 351-5290
