Ken Levy's July letter is up

Ken Levy's July Letter from the Editor is up on MSDN. Among other things, Ken offers a few additional comments on Sedna (announced earlier this month in the Visual FoxPro Roadmap) and includes a link to the slides from the Microsoft keynote at DevCon.

New FeedBurner Feed

Today I set up a FeedBurner feed for this blog. If you use a feed reader that doesn't support the Atom feed supplied by Blogger, you can now subscribe to the RSS feed via FeedBurner. If you're coming at this blog from its index page, you'll notice there are now two separate feed links.

Up until now I have been reluctant to sign up with FeedBurner, out of a vague sense I might be entering into a commitment I didn't fully understand and might not want to continue. But recently, FeedBurner announced that it now offers a graceful way out if you decide to stop using their service, and as a result, I'm much more comfortable with it. A fellow named Tom Coates posted a good analysis of this new FeedBurner service, which I found helpful. Judging from Tom's post and comments posted in response to the announcement on the FeedBurner blog, others have shared similar concerns and are welcoming this new service, too.

Behavior Changes in VFP 9.0: _TALLY

One of the SQL data engine changes introduced in VFP 9.0 affects the value of _TALLY returned after certain kinds of SQL SELECT statements. This change is not documented in the "Changes in Functionality for the Current Release" topic in the VFP 9.0 Help file, and may therefore have escaped the attention of some VFP developers. It is documented under the "SET ENGINEBEHAVIOR Command" topic, however.

The change is this: In previous versions of VFP, _TALLY returns zero when an aggregate function such as SUM() is used and there are no matching records, while in VFP 9.0, when an aggregate function such as SUM() is used without a GROUP BY clause and there are no matching records, _TALLY returns 1 and the result set contains one record with a null value for the aggregate function.

This change breaks code that tests the value of _TALLY to determine if any matching records were found.

To illustrate this, create a table of ten records with integer values and an ID of "foo".

CREATE TABLE myTable ( cID c(10), nValue I)
LOCAL lni
FOR lni = 1 TO 10
 INSERT INTO myTable ( cID, nValue) VALUES ( "foo", lni)
ENDFOR

Now perform a SELECT statement to SUM() the nValue of all records with an cID of "bar". Of course, there are no matching records. Under VFP 7.0 and VFP 8.0, the test for _tally = 0 returns true so Procedure A is performed.

SET ENGINEBEHAVIOR 70
SELECT SUM( nValue) ;
 FROM myTable ;
 WHERE cID = "bar" ;
 INTO CURSOR csrBehavior70
IF _tally = 0        && true
  DO Procedure_A     && Procedure_A is performed
ELSE
  DO Procedure_B
ENDIF

SET ENGINEBEHAVIOR 80
SELECT SUM( nValue) ;
 FROM myTable ;
 WHERE cID = "bar" ;
 INTO CURSOR csrBehavior80
IF _tally = 0        && true
  DO Procedure_A     && Procedure_A is performed
ELSE
  DO Procedure_B
ENDIF

Now perform the same test in VFP 9.0. With no other changes to the code, the test for _tally = 0 returns false so Procedure B is performed instead of Procedure A.

SET ENGINEBEHAVIOR 90
SELECT SUM( nValue) ;
 FROM myTable ;
 WHERE cID = "bar" ;
 INTO CURSOR csrBehavior90
IF _tally = 0        && false
  DO Procedure_A
ELSE
  DO Procedure_B     && Procedure_B is performed
ENDIF

The null value of the aggregate function can be seen in the one record in the result set:

SELECT csrBehavior90
?csrBehavior90.sum_nValue   && .NULL.

Although the best solution is probably to stop relying on _tally altogether, for this as well as for other reasons, one workaround in VFP 9.0 is to include a GROUP BY clause in the SELECT statement, which restores the result obtained in VFP 7.0 and 8.0.

SET ENGINEBEHAVIOR 90
SELECT cID, SUM( nValue) ;
 FROM myTable ;
 WHERE cID = "bar" ;
 INTO CURSOR csrBehavior90 ;
 GROUP BY cID
IF _tally = 0        && true
  DO Procedure_A     && Procedure_A is performed
ELSE
  DO Procedure_B
ENDIF

The changes to the SQL engine implemented by the VFP team in versions 8.0 and 9.0 have helped bring VFP's SQL implementation closer in line with SQL standards. This is a good thing, but watch out for changes like this one that might break existing code.

David Stevenson's Talking Fox

The number of VFP developers who are blogging continues to grow as well-known VFP developer and FoxTalk 2.0 editor David Stevenson launches his new blog called Talking Fox. Welcome aboard, Dave!

InstallShield Express News

Macrovision has announced the end of support for several older versions of InstallShield, effective November 1, 2005. Included in the list is InstallShield Express versions 2.0-3.x. Support will continue for InstallShield Express 5.0 and later. See the Macrovision End-of-Life Policy for the official announcement.

The InstallShield Express Limited Edition for Visual FoxPro that ships with VFP 9.0 is based on InstallShield Express version 5.0 and should therefore still be supported. The InstallShield Express Limited Edition for Visual FoxPro that ships with VFP 8.0 is based on InstallShield Express version 3.54, for which support is apparently ending.

The current version of InstallShield Express is version X (as in 'ten'). The InstallShield Premier and Professional editions are already at version 11. In an InstallShield webinar yesterday, InstallShield Product Manager Bob Corrigan announced that Macrovision will be releasing version 11 of the Express product in "mid-2005".

Beyond Compare 2.3.1 Released

Scooter Software today released Beyond Compare version 2.3.1. This point update fixes a startup issue under Windows 95, which surfaced in the recently released version 2.3.0, along with a few other miscellaneous fixes and changes. See the change log for a complete list.

It doesn't affect me personally, but kudos to the guys at Scooter Software for still caring about Windows 95. Hard to believe anybody is still running that old horse any more, although I'm sure I'd be surprised to know how many actually still are.