Views: VFP 9 Changed Behavior

I am working on a project to enhance an existing application, and in the process I am updating it from VFP 5 to VFP 9 (more stable, less filling). I thought I was going to take advantage of the multiple detail band features of the new Report Designer, but decided on another approach. The update from VFP 5 to VFP 9 has been smooth with the help of three lines of code:

SET ENGINEBEHAVIOR 70
SET REPORTBEHAVIOR 80
_screen.Themes = .F.


That is until yesterday...

The users acceptance testing revealed two bugs that are related. The application has some calculations on a report, and the calculations were evaluating incorrectly. The users pointed me toward a number not being included in the final results, but the formula definitely included the table column in question. It turns out that data was not being correctly pulled from the SQL Server database.

My debugging session showed no records in a certain scenario. I initially thought it had to do with the data in the base tables in SQL Server not having the conditions. and told the users they needed to set up data that met the criteria. They did and it still did not pull any data. Things that make you go hmmmmm.

What I found out in closer inspection is the original developer made a local view of two remote views. The code USEs the one local view with NODATA and later does a REQUERY(). Years ago I observed strange behavior with views based on other views and have stayed away from them. This situation is even "stranger" since it is a local view based on two remote views. Looking a the code, I never gave it a thought this was the case. I assumed (incorrectly of course) that this was a view pulling data directly from SQL Server.

In VFP 9, when you open a view NODATA, and the view is based on other views that are not yet USEd, the underlying views are also opened with NODATA.

In VFP 8 and earlier (I tested every version back to VFP 5), when you open a view NODATA and the other views are not yet USEd, only that view is opened with NODATA and the underlying views are opened with data.

Back to VFP 9, issuing the REQUERY() on the view requeried no records because the other views were already empty. Ugh. It was not the SQL Server data not meeting the criteria after all, it was the local cursors being empty.

The fix is easy: open the underlying views first, then open up the original view and REQUERY(). Fortunately the IT manager who is my customer understands how things like this can happen. He has been waiting to hear the "VFP 9 update excuse" during this testing period. He is a .NET developer so we had some fun jabbing each other's favorite developer tool.

I also tested this same issue with a local view of two other local views. Same behavior. It is not remote view specific. Unfortunately I cannot find any documentation in the Help file with respect to this behavior change, so I thought I would post it here and possibly save someone else some aggravation down the road. I never ran into this because I do not do view-on-view coding, but I know others do and this is something you should be aware of when you use this technique.

Debugger Frame Learning Experience

Last night Tamar Granor was in Detroit and stopped by the DAFUG meeting to present her excellent session "Using the VFP Debugger Effectively."

I have done sessions on the VFP debugger and think I have a good handle on debugging, but as usual for me in any session there were some points Tamar made that I was able to "relearn", and one particular point I did learn and wanted to share with you.

During the session Tamar mentioned the "Fix" feature of the Trace Window is available when you run in the Debug Frame, but is not available in the Trace window when running in the Fox Frame. The Fix feature directs the VFP debugger to cancel the execution and open up the current source code in the appropriate designer and code editor. This feature saves you the time of closing the debugger, getting to the project, opening up the source, and finding the line of code you want to fix. This took me by surprise as I thought I used the Fix feature, and I normally run the debugger in the Fox Frame.

Now anyone who knows me knows I have been very wrong about some VFP stuff in the past and this could be another one of those moments where I am imagining the behavior. So I open a simple PRG I was working with recently and ran the program in the debugger. Sure enough, when I right-click on the Trace window the Fix option is disabled. Hmm, I should not be shocked that Tamar is right and I am wrong, but I really thought this should work. I could just have easily been running with the Debug Frame when I use the Fix because I do switch to the Debug Frame when I want to load a debugger configuration from time-to-time (wish the Fox Team had time to add this to the Fox Frame too).

I have the program run a form (SCX). In the form's Init method I SET STEP ON. When the code stops I right-click to bring up the shortcut menu. Sure enough the Fix option is enabled and the form opens when I ask VFP to Fix it. I did the same thing in a class and the Fix option is enabled. Interesting - programs get the short end of the stick with the Fix feature. More importantly, if you are using PRG-based classes you are getting the short end of the stick with respect to this powerful time-saver.

The reason I was so sure it was available is I use Visual Fox Express for many of the projects I develop, and the code is almost entirely included in VCX classes. So the option is almost always available to me when I am using the debugger.

So do you think this is a bug in the debugger? Tamar is under the impression there might be some internal limitation the Fox Team cannot work around to get it the source code open when running in the Fox Frame. I am thinking if they can get it to open forms and classes, they probably should be able to get it to open the less complex PRG file. Unfortunately I also think this is a minor problem and I would rather they work on more complex issues before shipping VFP 9 SP2.