Home » Visual FoxPro » Visual FoxPro’s SET COMPATIBLE dangers

Today I tracked down a strange error “File does not exist.” triggered when the users were testing the built in Stonefield Database Toolkit (SDT) Reindexing capability inside their application. We just updated this application from SDT 5.x to SDT 6.2 so we did risk breaking some of the functionality. At White Light Computing we have an external utility (EXE) that runs the Reindexing, Updates, and Repairs. This utility works fine with the current set of metadata, which made me think it was an environment issue inside the application. Sure enough the code failing is in the DBCXMgr class in the FindProperty method.

lcLongName = padr(upper(alltrim(tcProperty)), ;
             fsize('cLongName', .cPropCursorName))

The FSIZE() function is one of the functions affected by SET COMPATIBLE ON (it defaults OFF). When the setting is ON the function is returning the actual file size. When the setting is OFF, the function is returning the size of the field. This is one of those design decisions you got to wonder about. I know Microsoft made it to make the code work for dBase developers, but I think it is crazy-nuts to reuse functions in this manner. It leads to time tracking down problems like this one.

The application we are supporting has a SET COMPATIBLE ON in the start up code for reasons unknown to me. This is a global setting and it would take a considerable amount of time to track down all the possible code I would break by turning it OFF making it high risk. One workaround I could have implemented around this problem is inserting the SET COMPATIBLE OFF before the call to the SDT code and resetting it ON after the call (low risk, but only fixes this application). I decided to modify the FindProperty method to set and reset because it could be called by other application that use the DBCX Manager code. I also sent the findings to Stonefield support for their consideration.

[EDIT * 2-Feb-2011]  I have since realized that the changes are necessary throughout the DBCX Manager code. After further consideration, both Doug and I have come to the same conclusion, there are to many places to fix the code in the DBCXMgr, and no good reason why SET COMPATIBLE should be set ON. So I have changed the application to toggle the setting before calling the SDT Reindexing, Update, and Repair functions.

Glad to have that one off the bug list for our customer.

One Response to “Visual FoxPro’s SET COMPATIBLE dangers”

  1. February 2nd, 2011 at 21:33 | #1

    Hey Rick,
    We also had issues with SET COMPATIBLE during the GdiPlusX library coding. Finally, we ended by turning it OFF internally as you did.
    In fact, I think that most people use it just because someone recommended them to do so. When the issue appeared with GdiPlusX users, when I asked them they all (about 4 people) did not know the purpose of having it there.
    Another case of function used without knowing the reason, is SET UDFPARMS. Many people use it without knowing the purpose of it :-D

Add reply