What's the width of a combo list
If you have a combobox for which you don't specify a value for the ColumnWidths property, Visual FoxPro has to figure out itself how wide the dropdown list should be. Basically, Visual FoxPro makes this list just wide enough to fully display its values. However, Visual FoxPro only parses part of the list to determine the actual width of each line. The following code sample demonstrates this behaviour:
Public goForm, gaData
goForm = CreateObject("Form")
For lnRow=1 to 120
gaData[lnRow] = "_"+Transform(m.lnrow)
gaData = "AAAAAAAAAAAAAAA*"
* first combo
goForm.c1.RowSource = "gaData"
goForm.c1.RowSourceType = 5
goForm.c1.ListIndex = 1
goForm.c1.Visible = .T.
* second combo
goForm.c2.RowSource = "gaData"
goForm.c2.RowSourceType = 5
goForm.c2.ListIndex = 100
goForm.c2.Top = 50
goForm.c2.Visible = .T.
Both comboboxes are set up with identical row sources. The only difference between the two is the currently selected item. The first combo displays the first item, the second one an item that is close to the end. If you now open both comboboxes, you will notice that the first one is narrower and won't display the last item at its full length.
VFP uses the current element and then reads a varying number of lines. In the sample above it's always 68 on my computer. That is, with a ListIndex of 53, the combobox behaves like the first one, with a ListIndex of 54 like the second one. In other cases I found the number lines to be much more like 10 putting the long line just outside the visible area of the seven default lines.
Translating Oracle's NVL2 function to Microsoft SQL Server
Technet Microsoft states that
the proper translation for Oracle's NVL2 function:
NVL2 (Salary, Salary*2, 0)
WHEN null THEN 0
They got the Oracle part right, but miserable failed on the syntax of their own server. The correct way
to use CASE with NULL values is
WHEN SALARY IS NULL THEN 0
In Microsoft SQL Server you use IS NULL and IS NOT NULL to check for NULL. The original expression would
always return the value from the ELSE part since the condition SALARY=null never becomes true.
FileMon is a great utility if you need to debug performance problems in a Visual FoxPro application. After launching FileMon.EXE as an administrator change the filter to "VFP9.EXE" or the name of your application. When you now run your application, you can see all disk activities in your application.
One major pattern to watch out is a long list of read accesses on a single DBF file. These are usually table scan that are the result of un-optimized queries or frequent aggregations such as calculating sums or counts. When you test on a local machine you rarely notice these operations as a delay since your hard disk is fast enough to read dozens of MB in just one second. On a shared network, though, bandwidth is really criticial.
FileMon is pretty good at telling you what went wrong. However, it doesn't help you to relate this with the actual line numbers in your code. To achieve this I use markers in my Visual FoxPro application. A marker looks like this:
That is, I check for the existence of a not existing file. In FileMon this line produces output similar to the following:
11:14:08.182 vfp9.exe:2776 FASTIO_QUERY_OPEN
C:\DOCUMENTS AND SETTINGS\CHRISTOF\MY
FILE NOT FOUND Attributes: Error
Now I can search for my markers in FileMon. I can be confident that all activities between two markers have been caused by the code between the two markers. By adding and moving markers I can quickly identify the lines that cause most traffic in an application.