Tuesday, February 26, 2008

Rerun: Concentric Hosting is Currently Down AGAIN - and up again!

Back in December, I found that my hosting partner, Concentric, was down : Andrew MacNeill - AKSEL Solutions: Concentric Hosting is Currently Down

And now today, it decides to go down again.

At that time, I wrote that it was only the SECOND time in 10 years I had lost service, but now this is three times and twice in the past 3 months.

They came back on a few minutes ago (around 12:45 EST)
Thankfully the outage was only an hour and a half. Strike 1 was in December...this was strike 2.

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"
while
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:

INDEX ON clientID TAG MAINKEY FOR myFlag="A" CANDIDATE

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.   

Screencast on Advantage Database Server

Over on Shedding Some Light, Rick Schummer notes that JD Mullin has a demo of how to get started with VFP and the Advantage Database server. I'm glad to see these types of demos get put up more and more by the people behind the scenes of a product instead of just the marketing types.

I did a FoxShow interview with JD over at the start of the month and he really goes into details about what the ADS is and what it isn't.  

Monday, February 25, 2008

VFPX & FoxPro Community - Quiet? Hardly

I keep on doing Google Searches for VFP and Sedna or VFP and VFPX to gauge traffic. It's not scientific and by in large, I use my own news aggregators for real check-ups but I like to use Google every now and then to get a reality check outside of the VFP blogosphere community.

If you do that, it would seem there isn't that much activity in the VFP world since Sedna (many searches would suggest discussions started to dissipate after mid-2007.

But this is hardly the case. Over the weekend, I noticed that Craig Boyd has continued to take it upon himself to refresh the VFPX site over at CodePlex, ensuring that ALL of the public-licensed code is now available for updates, including all of the XSource pieces and more.

Although I'm not quite sure I like the idea of prefacing all of the base VFP Components with XSource, (especially since now WE are responsible for the growth of VFP), this is great news for everyone.

Why? Let me take one tool that doesn't get a lot of respect: the Task List tool. No, it's not that sexy and most developers likely have their own individual tools for tracking their "To do" lists, perhaps through bug tracking systems or others.

And the UI for the generic task list is kind of bland. However, with a few little tweaks, it could be just as useful as the one found in Visual Studio. Consider the following possible ERs:

1 - Dockable UI (I've done this in my own environment and it definitely makes the tool usable)
2 - a possible project hook that would automatically add any compile-time errors to a
3 - integration with the Code Analyst
4 - task filtering

A lot of developers think about FoxPro as one big IDE and while it appears that way, its extensibility lets us deal with and improve the individual components to match our own development styles.

Rick lamented at the German conference that he learned that VFPX was not really well known in the VFP community. I don't know how many people use the Community Task Pane ( I do every now and then - as it's linked to FoxCentral.net) to find out what's going on but this might be one way.



VFPX - Home

Wednesday, February 13, 2008

Doh! - figure out return values before coding for them

Many developers will tell you "Development is full of "aha" moments" - those moments when something clicks and everything falls into place. What they don't tell you is that there are also a few "doh" moments - moments where you see code (usually your old code from years back) and instantly see why it wasn't doing what it should have been doing in the first place.

So here's a recent "doh" moment in VFP.

I'm tracking some strange behavior issues in some CursorAdapter code and figure I can use the AfterRecordRefresh event to see if I did get a refresh or not.

I have a lot of my code wrapped in a TRY CATCH LOOP but I had a little piece of code outside of it that I wanted to trap why a record was not refreshed.

The AfterRecordRefresh event gets three parameters:
nRecords - The number of records to refresh (passed to the recordrefresh method)
nRecordOffset - The record offset passed
nRefreshed - the return value from the RecordRefresh method

So the code was...

IF nRefreshed = 0
    ** Log this so we can see why no records were refreshed
ENDIF

Anyone catch the "doh"?

(for one, the documentation is this case is incredibly convoluted to follow. The AfterRecordRefresh method gives you some basic description but essentially says "See RecordRefresh" - once a doc goes into "see this" mode, it can often get overlooked.)

If you refreshed one record, nRefreshed would be 1, right?
If it didn't succeed, it would be .....

The "doh" is that RecordRefresh returns zero if there were no records were refreshed and there were no errors. If there were errors, it returns -1. Now, that's what I wanted to track down with.

So the code was recording any time an update was done, even when there were no changes.

Who reads the docs anyways, right? RTFM!

Thursday, February 07, 2008

Using Debugger Configuration files

Andy Kramek has a great post explaining Form Event Sequences in VFP and while reading it, I was also debugging a piece of code in which I had the fortune (or misfortune) to use the Track Events feature in the Debugger. (what do the two have in common? You can actually see the Form Event Sequences very easily by using the Track Events feature).

Track Events is one of those features that doesn't appear useful until you actually need to use it. The big problem is that you have to spend quite a bit of time either a) selecting each event you want to track OR b) selecting all and then removing the events you don't need to track.

Some basic events whose tracking simply takes up space and I almost always turn off:
Paint
MouseMove
MouseEnter
MouseLeave

One feature that I don't see used that often by other developers is the ability to save the Debug configurations. The debugger typically retains all of the settings from the previous session so why would you need to save a separate configuration, right?

The Debug configuration saves all aspects of your debug environment: your breakpoints, your event tracking and your watch window. But when you're in the heat of development, you may find yourself creating so many breakpoints or watch items that it's hard to keep track of. Here are some reasons you may want to save it:

1) You work on multiple projects (clients?) and want to retain a particular debugging environment for one client while using another for a different client

2) You want to maintain different configurations for different types of debugging sessions (looking for events, waiting for click and valid events, etc).

3) You are working on a particular problem and have to step away for a minute.

So what's in a configuration file?

Debug configuration files have a DBG extension and are simply text files that can be easily parsed or created on the fly. Here's a sample:

DBGCFGVERSION=4
WATCH=llreporun
WATCH=PROGRAM()
BPMESSAGE=ON

BREAKPOINT BEGIN
TYPE=3
CLASS=    
LINE=0
EXPR=fl_btnok
DISABLED=0
EXACT=0
BREAKPOINT END

BREAKPOINT BEGIN
TYPE=0
FILE=c:\health\illcheck.prg
LINE=51
DISABLED=0
EXACT=0
BREAKPOINT END

BREAKPOINT END

EVENTWINDOW=ON
EVENTFILE=
EVENTLIST BEGIN
Load, RightClick, Valid, When
EVENTLIST END

The DBGCFGVERSION is important. VFP 9 won't load any files that have a value of 4.

The first part is the WATCH area, followed by the BREAKPOINTS.
The Breakpoint type is evaluated as:
0 - Break at location
1 - Break at location if expression is true
2 - Break when expression is true
3 - Break when expression has changed

If you use the Pass setting, it also adds a PASS=xxx setting within the BREAKPOINT area.

One thing that DOESN't get saved in the DBG file is what debug windows were open. Also note that if you choose Restore to Default from the Window menu, it doesn't just restore the windows to their default position, it clears out all of the settings as well - another reason to save your commonly used debug configurations for future use.

How do you use the debug configuration files?