Re: while .not. tbl.fetch_eof() not working
Hi Cal,
What you said is true for both append and update operations. If the index have to be updated (always for an append operation), and if an update field is used in any index for an update operation). However, if another thread has the table open (e.g. a form is open) or another user is using the table, then the indexes are updated on the fly after processing each record.
To guarantee that Alpha uses the latter, I always open a form based on the parent table of the operation, as in the code
frm=form.load("tablename")
update.run_silent("updateoperationname")
frm.close()
If you do it by the above code method, it will run much faster if your Update filter invokes LQO (if using a subset of the table). Tests on a 35000 record file had an update take about 11 seconds in the above method, versus 19 seconds for the index rebuilds happening at the end (index expressions are very complex for this table) when the table is available exclusively.
As you and I recently conversed about, measuring code speed for short time events is difficult, and the profiler functions of A5 gave wildly inaccurate values to the execution speed differences in the case you and I discussed. The only way to get an accurate time result is to run short time code pieces many times over, and make sure the loop overhead is not significant. The second part can be difficult to do.
The accurate speed timing button of my CSDA Code Utility for Alpha Five does just that.
So to get to Tony's question, is the overhead of an update faster than parsing through the records?
For large numbers of records where either the index rebuilds don't take long, or using the method shown above to update indexes on the fly, normally the answer is yes. For under 10 records, it is probably faster with code, with 10 to 100 records probably being the cross over point. It's even possible to use both methods, depending upon # of records to process, if the value changes dynamically.
Hi Cal,
Originally posted by CALocklin
View Post
To guarantee that Alpha uses the latter, I always open a form based on the parent table of the operation, as in the code
frm=form.load("tablename")
update.run_silent("updateoperationname")
frm.close()
If you do it by the above code method, it will run much faster if your Update filter invokes LQO (if using a subset of the table). Tests on a 35000 record file had an update take about 11 seconds in the above method, versus 19 seconds for the index rebuilds happening at the end (index expressions are very complex for this table) when the table is available exclusively.
As you and I recently conversed about, measuring code speed for short time events is difficult, and the profiler functions of A5 gave wildly inaccurate values to the execution speed differences in the case you and I discussed. The only way to get an accurate time result is to run short time code pieces many times over, and make sure the loop overhead is not significant. The second part can be difficult to do.
The accurate speed timing button of my CSDA Code Utility for Alpha Five does just that.
So to get to Tony's question, is the overhead of an update faster than parsing through the records?
For large numbers of records where either the index rebuilds don't take long, or using the method shown above to update indexes on the fly, normally the answer is yes. For under 10 records, it is probably faster with code, with 10 to 100 records probably being the cross over point. It's even possible to use both methods, depending upon # of records to process, if the value changes dynamically.
Comment