Shedding Some Light

Microsoft moved all bug reporting for VFP to their Connect system years ago. The FoxPro Community followed the Microsoft direction with some kicking and screaming. One of the drawbacks of this was the VFP reports went through the Visual Studio group and we never got the feeling of being a first class citizen in the process.

Microsoft has fixed this. Well, sort of fixed this. {g}

About a month ago Gianni Turri posted a message on the ProFox list server noting a bug report he posted was rejected with the following message:

Thank you for submitting this Connect Issue. Visual FoxPro is no longer supported though Connect. Please use the Visual FoxPro Support Center (http://msdn.microsoft.com/en-us/vfoxpro/bb190294.aspx) or the Visual FoxPro Discussion Forum on MSDN (http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=60&SiteID;=1) for more information or suggestions. You can also contact Microsoft Help and Support (http://support.microsoft.com ) for further assistance. For additional information please visit the Community Resources page on Visual FoxPro MSDN site (http://msdn.microsoft.com/en-us/vfoxpro/bb190227.aspx) as well as the VFPX project on CodePlex (http://www.codeplex.com/VFPX). Thank you, Visual Studio Product Team.

[Editorial note: interesting plug for VFPX - yeah!]

I confirmed this with Milind Lele. He told me Microsoft Connect is great for products in continuous development and allows better management of the reports to flow into the next release. All Visual FoxPro bug reports need to go through Product Support Services.

To get to Product Support Services you go here: http://msdn.microsoft.com/en-us/vfoxpro/bb190294.aspx

Near the bottom of the page you will find “Get Help from Microsoft”. Click on Assisted Support. Scroll through the list of products to find Visual FoxPro 9.0 (or 8.0) and click on the link. Or you can go to this link:

http://support.microsoft.com/oas/default.aspx?Gprid=7992

You will see three options:

1. Email Support (24 hour response time, two free incidents, US$99 for support)
2. Online Request to be called (US$259 per incident, response time based on severity)
3. Request by phone (US$259 per incident during business hours, US$515 after hours)

Other options for contracts are available.

So I asked about “paying” to report a bug. You do initially have to pay if you are past your two free support emails. But if the support people determine it is a product bug (their definition of being out of spec, not your perception of what you might consider a bug), your payment will be credited. Exact words from Milind:

Actually for a valid bug, the charges get reverted. The quickest way to get a fix is to have a hotfix issued. And the fastest and surest way to do that is to create that request from support.

The good news: you will be routed to the folks that know VFP best and in my opinion, some of the sharpest folks supporting software anywhere. Plus the reports are going directly to them, not through a system that treated our favorite product as less than first class.

My recommendation: if you think you have run across some “buggy feeling feature” in Visual FoxPro, post the issue on one of the forums. Let the Fox Community help you flush out any issues to see if it is indeed a bug. Then report it though the Product Support Service channel.

I received a bug report this week for ViewEditor Professional that took a little time to track down. I don’t have time to immediately fix it so I want to pass this along to the developers with two simple workarounds to use until I can figure out the best solution.

The bug is only revealed under a specific circumstance and has likely been a bug since ViewEditor Professional was originally written back in 2002. The bug shows itself when you save the view you are working on. The save process verifies the view’s SQL code is valid and reports any problems with the SQL code. During this process all view parameters are substituted using the VFP STRTRAN() function. Depending the substitution sequence of the view parameters and the names of the view parameters, an incorrect substitution occurs. The problem only happens when you have two view parameters starting with the same characters.

?vp_lActive = .F.?vp_lActiveArchive = .T.

SELECT cCustomerID, cCustomerName ; FROM Customer ; WHERE ?vp_lActive = .T. ;    AND ?vp_lActiveArchive = .T.

If vp_lActive is STRTRAN’ed first you see the validation code after the substitution to be:

SELECT cCustomerID, cCustomerName ; FROM Customer ; WHERE .F. = .T. ;    AND .F.Archive = .T.

The two workarounds (use one or the other):

1. Do not name your view parameters starting with the same characters.
2. Shut off the validation process when saving views by unchecking the Validate SQL checkbox on the SQL page.

If your views give you an error when you are saving them you can click on the Show SQL Validation Code button to see what the ViewEditor uses as the validation code. This is how I revealed what happened with my customer’s view. She knows the view is valid and has decided to shut off the validation until I can the validation substitution of view parameters.

I have talked to a lot of Visual FoxPro developers since VFP 9 SP2 was released in October 2007. I have read many of the posts on the forums. In my unscientific poll I can safely say that less than 20 percent of the developers have even loaded SP2 and there are a number of reasons for this:

1. Developers are comfortable with the stability of SP1 and don’t need any of the fixed bugs deployed in SP2.
2. Some developers do not have the resources to system test all of their applications and cannot adopt the new service pack until the resources can be allocated to their projects.
3. The first release of VFP 9 SP2 eroded the confidence of VFP developers because of the missing fixes, and the “beta” splash screen.
4. The reputation of SP2 is further eroded because of the number of serious regression bugs discovered since the release of “SP2a” (however, most developers are going on the experiences of a few who have blazed the SP2 trail, and have not loaded it themselves).
5. Developers do not understand you can have VFP 9 no service pack, VFP 9 SP1 and VFP 9 SP2 loaded on the same development machine.
6. Anger at Microsoft over the decision the product is feature complete, and the sloppiness of the release cycle for VFP 9 SP2.
7. Something else?

I believe the biggest reasons are the confidence eroding regression bugs posted by the trail blazers, and the fact many developers have not considered the possibility you can host more than one version of VFP 9 on the same machine.

There is a big problem with this situation, and one really concerning me. The problem is that too few people have installed, tried, and tested the release of VFP 9 SP2. This means the brave few who have installed it possibly have revealed only a subset of the problems with SP2. I am confident that the most serious and obvious problems have been revealed. But more developers running their code through the release will better establish the complete list of issues we might have to work around for years to come.

You can see the current list on the Visual FoxPro Wiki’s VFP9Sp2BugList page. You can also see some of the workarounds for the bugs on the SolutionsToVFP9SP2Bugs page. I would like these two pages and other pages added if necessary to this important knowledgebase so the Fox Community has a centralized list of the best practices in dealing with VFP 9 SP2 issues. These pages are referenced over and over as developers come online with VFP 9 SP2 and hit the same problems others have already solved. It also allows developers supporting each other a place to refer developers who are new to SP2 where to go to get key information.

As to the new regression bugs without workarounds, the sooner we can identify these the better. The identification of the problems has a potential four-fold advantage:

1. Developers who are making the business decision to adopt or not adopt VFP 9 SP2 will have the best information when testing and certifying their decision.
2. A centralized set of best practice workarounds for core VFP9.EXE problems is continually refined. Bugs in the VFP XSource components can be identified and a plan to make corrections by the Fox Community can be put into motion through VFPX.
3. If more developers adopt SP2 the Fox Community as a whole have an easier time supporting each other on the online forums.
4. A business case to have Microsoft consider fixing some of the serious regression bugs without reasonable workarounds can be developed and presented to Microsoft. The sooner we can do this, the better the chance it will be considered. And please, never say never.

I know by myself I cannot turn the tide with respect to the eroded confidence, but if more developers give SP2 a try we can take advantage of the benefits I have outlined in this blog post. Those developers with a positive SP2 experience need to post their successes too. Too often humans focus on problems than the positive experiences, and the positives get overshadowed.

I definitely want to see the best practices flushed out and fixes applied to the XSource code. Several have already been identified to ease the adoption. If we can identify the VFP 9 core EXE show-stopper bugs to Microsoft and get those fixed, big bonus!

To help those who have not loaded VFP 9 SP2 on their development machine I have written a short white paper detailing the steps I have taken to load VFP 9 original (a.k.a. RTM – released to manufacturing), Service Pack 1 (SP1), and Service Pack 2 (SP2) on my primary development machine. This white paper is available for you to review and help guide you to install more than one of the VFP 9 versions. This process has been refined over the years and others have stepped through it, so it is tested by more than one developer.

If you are interested, you can find the white paper here:

1. PDF file (584K)
2. ZIP file with Word document (747K)

I am open to any feedback about the white paper and the process for the installs. I have identified the feedback mechanism in the white paper. I am sure people will see different things they want to do to make it work better. As I have noted, this process works for me and is being provided as a guide to get you through the challenge and give you some food for thought on the process.

If you are one of the those important language translators in the community (and you know who you are) and you want to translate this document to your native language, please do and let me know so I can also host it on my Web site too. I have granted general permission to everyone who has ever requested permission to translate blog posts over the years. This information should not have artificial barriers because people cannot read my writing (and no comments from the peanut gallery on my English {g}).

Special thanks to Pamela Thalacker, Mary Pilon, Tamar Granor, and Cathy Pountney who kindly responded to my request to review this document. They helped me think thorough many of the steps and offered gentle advice on improving it. This document is better because of their help, but any bugs or confusing details you may find in it are all mine.

Call To Action!

It is my hope you will install VFP 9 SP2, and will post your VFP 9 SP2 issues on the Visual FoxPro Wiki so we can identify the best practices and workarounds discussed. I also hope you will post some discussions on the various community forums. I cannot promise to engage in all the discussions because I am only one person and having an expanding customer base to serve in my day job, but this is what the FoxPro Community is all about, masses of people helping each other out.

Enjoy!

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.