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.   


Unknown 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

Well, that explains CodePlex...

In a move that will be sure to anger open source (or rather anti-paid software, anti-Microsoft open source)  zealots, Microsoft is planning to buy GitHub.

A year ago, I mused about why Microsoft would shut down CodePlex and how the world needs competing source code repositories to be strong. I'm not the only one per this Slashdot article :
"...people have warned about GitHub becoming as large as it did as problematic because it concentrates too much of the power to make or break the open source world in a single entity, moreso because there were valid questions about GitHubs financial viability...." - Jacques Mattheij

I will be interested in seeing this play out - whether developers jump ship or not. Have all the efforts Microsoft has made in pushing towards open source be seen as genuine or will all the zealots jump ship or maybe even attack?

Microsoft's comment about why they shut down CodePlex referred to how spammers were using CodePlex. Well, GitHub has its own …

FoxInCloud Stats

FoxInCloud sent this link a while back about their statistics regarding visits to their site:

What's interesting here is the breakdown of people. Yes, I think it's understandable that the Fox community is getting older.

Another factor is the growth of the mobile and web environments taking over development. These environments really do push people towards the newer non-SQL or free SQL/hosted environments but more towards hosted storage options like Amazon and Google. A tool like FoxInCloud that helps MOVE existing applications to the cloud inherently competes with those environments.

But FoxInCloud also allows developers to extend their application further by giving them a starting point using Javascript and the basic CSS (such as Bootstrap). If you're not rebuilding your application from scratch, it's certainly a great step forward.

The World of Updates Today

I just received an update for Office 365. It certainly includes some cool features - including starting in one environment and picking it up in another environment. In recent years, I've certainly enjoined the use of Continuity on a Mac and in fact, I feel spoiled being able to start a message in one environment (even Google) and then finish it off on another.  This has become some pervasive when we were reviewing our most recent backlog at a client site, a similar feature was added to the current workload.

But with web applications, the trend is to reduce the amount of software on a client machine. I used to have automatic backup for all of my machines (thanks Carbonite!) but these days, many of my machines don't need anything beyond the core OS and some basic applications. Certainly that's the feeling with Chromebooks and even the lightweight aspect of many iOS apps. The functionality is mostly in the cloud.

When you upgrade your system, you expect it to a big update. So…