Skip to main content

Learning the Basics

Working with FoxPro developers with different degrees of knowledge, it's interesting to see where the general knowledge line is. What do I mean by that?

If you put a bunch of FoxPro developers into a room and talk about standards, you get one indication of where their technical level is at. Yet when you look at the code behind the scenes of individual applications, you can get an entirely different impression.

I've had two (well more actually but two will illustrate it) situations where this came up. Someone was running a query where the results had more records than were expected. When I looked at the query statement itself, the WHERE statement was TRIM(tablea.field1) = TRIM(table2.field2). So that was the problem but why was that in there? As it turns out, it comes back to misunderstanding one of the basics of FoxPro comparisons:

x = "John"
y = "Johnson"

? x=y && Returns False
? y=x && Returns True

Why? Because when FoxPro compares two values, it essentially forces the text of the first value to match the length of the second. In short,

x  = y  is really does "John   " (3 spaces) = "Johnson"
y = x becomes "John"(son) = "John" - so only the first four characters apply.

This is without SET EXACT ON , or x == y which does the implicit forcing the length of each string to be the maximum.

Update: As noted in the comments by Sergey Berezniker, the problem in the Query above had more to do with the SET ANSI statements than with the exact (he has a great post about this here).

The lack of understanding of how information is compared is what I was trying to get at and Sergey, your post gives a great set of examples on this. Thanks!

Another scenario was when a client was troubled over problems with their primary keys in their system and getting errors. Upon looking at the tables, I saw that their tables had a number of indices and they were using a flag to identify "deleted" or "archived" records. But more troubling was that what they considered to be their primary key was:


Then when their application made a particular update (like changing the myFlag field), the system would bomb out with a Violating Index error.

Even more so, there were indices based on
INDEX ON TRIM(custname) TAG custname

Similar to the above discussion of comparisons, it shows a basic misunderstanding of how items are put together. (I've seen FoxPro developers creating TRIM indices and then wondering why their code still runs slow with huge tables).

Certainly the Using Rushmore Query Optimization topic looks helpful or even Craig's short version but it still doesn't get away from the problem that likely exists in lots of older code.

So what's the answer? Basic Training obviously - but where do you get it? I had started a while back with a site calling Learning Visual FoxPro where the goal was to point people to great starting resources. But the problem with a lot of training is that when you discuss features and then the ideal way to do things, users can still go out and make bad choices (like creating filters on indices for primary keys).

On the Wiki, there's a topic of Learn VFP in 21 Days which has a great outline for getting started but what I think is missing is a "What NOT to do" or maybe it's more of a "what not to do unless you absolutely know what you're talking about" <g>

As it turns out, there is such a page on the Visual FoxPro Wiki but it's VFP Rookie Mistakes (does that make anyone feel smug when they find code that is in there?). To be fair, there is VFP Misused and Abused but once again, it's hard to find it. It seems like some refactoring of those Wiki pages may be in order.

If anyone has found any other "things not to do", be sure to add them to the site or let's discuss them here.   


Sergey said…
Hi Andrew,

Your explanation for the first scenario is totally of mark.
Comparison in a query is controlled by SET ANSI setting, not SET EXACT. Also, in a query it doesn't matter if shorter string is on the right or on the left.

Andrew MacNeill said…

Good point. I wasn't referring in my first scenario however to the ANSI or SET EXACT statement. I was referring more to the poor use of TRIM() in a query.

But thanks for the note - good to know.
Andrew MacNeill said…
That page is awesome, Sergey.

Tamar E. Granor said…
Andrew -- thought you'd want to know that I'll be doing a series of articles in the forthcoming FoxRockX under the title "We Used to Do it That Way, But ...," in which I discuss things which came into the language somewhere along the way and people may not have noticed.

The first article in the series is about the JustX() and ForceX() functions for handling files and paths. The second covers the different looping constructs in VFP.


Popular posts from this blog

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator)

So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinctions I…

Security in Windows 10

 discusses some Windows 10 privacy settings and their implications.

"Finally, we will access, disclose and preserve personal data, including your content (such as the content of your emails, other private communications or files in private folders), when we have a good faith belief that doing so is necessary." "In other words, Microsoft won't treat your local data with any more privacy than it treats your data on its servers and may upload your local data to its servers arbitrarily"
I did a quick install on a VM choosing the Express settings. When I fully deploy this on a real workstation, I will likely choose to wade through all of the individual pages, as David recommends.

Of course, losing one's privacy is nothing new - it's happening all over the place (despite Santa Ana's police force's lawsu…


I'm not TRYING to be "fanboy-flame bait" but what I saw yesterday was a typical "Do it this way, now do it this way and then we'll go back to this way" all over again.... a move similar to what Microsoft does to developers on an ongoing basis.

Remember the first iPhone? Smooth and curved, at least as far as it could be back then. I still pull out my 3G and can see the curves on it.

Then the 4 came out and "boxy" was all the rage. Everything should be "tight with corners"

Now iPhone 6.... smooth and curvy is back. Granted I don't have the actual device yet, but that's the message.

Guess that means the iPhone 8 will be back to boxy.

And honestly, Apple Watch is not worth "one more thing" --- especially when everyone knows it's going to be shown. "One more thing" would be something no one saw coming.  The device itself ? Very interesting and yes, definitely lots of potential but "one more thing" wor…