I was working at a place that did ran batch processes at night using VFP. One of the managers came up to me and told me of a process that used to take 30 minutes now was taking 5 hours. Combined with the other processes, this meant we couldn't complete the processing overnight any longer and meet our deadlines.
I pulled the latest code into my test environment, and via logging I traced it down to one SELECT statement. It turns out one of our developers changed the code to read "WHERE B=A" where prior it was written "WHERE A=B". (Thanks source code control for allowing me to pinpoint when the change was made!) That small code change meant it no longer could take advantage of Rushmore and was basically doing a table scan. SYS(3054) is forever my friend. We were back to 30 minutes for that process and back on schedule without any major effort or rework.
I spoke to the developer who made the change and she didn't realize that a small change like that would affect performance in that way. It was logically the equivalent behavior. A great learning moment.
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Sunday, March 18, 2018 2:34 PM To: ProFox profox@leafe.com Subject: Testing tells the tale (SYS 3054) -- "BETWEEN(a,b,c)" equivalent to "a BETWEEN b and c"
VFP9SP2 WestWind WebConnection App on WinServer 2012
I was looking at a notoriously slow query to see about optimizing it. Using SYS(3054,11,"cmemvar"), I was able to do so, but during my testing, I found that using MyDate BETWEEN Arg1 and Arg1 was the same optimization-wise as BETWEEN(MyDate,Arg1,Arg2). Somewhere in history, I thought that using VFP's native BETWEEN(field,d1,d2) was NOT Rushmore friendly. However, testing with SYS(3054) showed otherwise!
Just an interesting find this weekend for me whilst debugging.
Carry on! --Mike
[excessive quoting removed by server]