First, Ed, let me say that there is a difference between 'commands' (and their results) and something like 'weak typing' (which is decidedly not a command). Really don't know why you feel you have to get snarky on the issue.

Now, about the documentation...

While I too do not expect any documentation to tell me WHEN to use a specific command or set of commands, I do expect any product's documentation to tell me the essentials of each and every command/function/P-E-M/etc.

VFP has far too many deficiencies to fully enunciate here, but let me offer a coupla bigger ones:
1) Just where are the "default" (as far as DODEFAULT or NODEFAULT) behaviours documented?? Just a small thing.
2) Why does SET REFRESH continue to be basically the same as it was documented in FPD - that is, being applicablew to BROWSE only????
3) Just yesterday AddItem/AddListItem came up again. Despite reading the documentation there was still no way to use it 'intelligently'.
4) Just what is "scopes to the datasession"??? Can a noovice really be expected to understand the implications of that simple statement???
5) Just how do LOCK/UNLOCK/RLOCK/FLOCK act/react in a buffered situation???
6) Why does the absence of a ReadEvents come up so often???... as in 'my test runs OK but when I try a regular run the form just flashes up and then disappears?'

Sure, those of us who have been with FP/VFP for quite a while have learned about these things. But think of the frustrations even you encountered when you first started. They may be long ago and forgotten now, but is it right that every newcomer should have to face the exact same set of frustrations???... Isd that 'progress'??? Is that any way to expand the VFP user base???

Maybe we do have differences in our expectations. And possibly the fact that you work at a publisher's makes the concept of having to buy supplemental material a little less troublesome to you.
But consider that even the authors of VFP books do **NOT** have the full "inside scoop". Their writings are based purely on the substandard documentation that we all have to work with PLUS a very deep level of experience. Yet, as we recently saw with the TAG on DELETED() thing, the base can change **WITHOUT** adequate advice in any product documentation. So, really, just how reliable can this supplementary documentation be???

VFP's documentation leavers far far too much of the BASIC stuff out, leaving one to assume/guess. This is simply wrong.

regards,

Jim N

>>>I don't think that Jim's point is that he can guarentee that a filtered view can/will be used by a given query; more to the point, he codes so that it doesn't matter which way the cursor is implemented. The idea is to understand what the cursor is intended to do, and how it is intended to be used. If you're dealing with the result of a read-only query on a set, as opposed to a record-oriented, basis, it really doesn't matter how it has been presented. if you're still dealing with cursors procedurally, then filtered cursors are a bad thing, and you can add NOFILTER to the query to make it clear to VFP that you require a distinct seperation of the data from the underlying table.
>>>
>>
>>OK, that's not how I read it, but let's assume that your interpretation is correct. The point is that Jim would have learned this in the school of hard knocks and most definitely *not* from the FP/VFP documentation. Even the present version of the documentation doesn't mention the differences to be on the lookout for between the two possible results. What chance does a novice have???
>>
>
>There is an explanation of the idea of filtered cursors in the documentation, and there is a reference to the NOFILTER clause. While the VFP documentation is not everything I'd want it to be, it's designed as a reference, not a tutorial on best development practices. When I wanted to learn to program in C, I didn't rely on the language reference guide to teach me - I bought K&R, and Plauger's Software Tools (and a lot of other books) and worked at it. I still haven't mastered all the nuances of the C programming language by a longshot, and I've read a lot. I haven't got VFP down competely, either; I pick up plenty from other books, magazine articles, and from tips and tricks on UT. If I wanted to learn best practices for VFP, I'd turn to books outside of the VFP documentation (Like Jim's Effective Techniques) as a good starting point.
>
>Maybe you're better at learning programming languages than I am, but I've yet to pick up the flavor, methods and best practices of a language from the reference manual.
>
>I think that we expect different things from the VFP docs; I want them to be a complete reference, so that once I decide I need to use a command or function, I have a comprehensive and exhaustive explanation of the syntax. I don't expect a reference book to tell me when to use a command, any more than I expect a C reference to tell me when printf() and sprintf() are the right choice of function to use.
>
>I'd be happier if the VFP help were to include many of the nuances to VFP like the Hacker's Guide to Visual FoxPro 6.0, but I don't expect someone to be able to learn to write good VFP by picking up a copy of Hacker's Guide, either.
>
>>
>>>>In addition, if (one of) the determinants of filtered vs cursor is the size of the result set, then is it not possible that the apps in question typically work with small results sets? *IF* this is the case, then why would a cursor present a speed difference of any substance???
>>>>
>>>
>>>Because of the data that must be moved over the wire to make the cursor available. Using NOFILTER means that the cursor must e extracted and created independant of the base table it has been created from. In a local or LAN environment, this may not be a significant number, but with apps distributed across a WAN, copying data ahead of time has a cost, and if the data only needs to be read, there's a more noticable enhancement of query performance. A delay that's immeasurable on a 100Mbps Fast EtherNet may be significant on a 56Kbps WAN link.
>>>
>>>>I'm betting that, for the few who feel that there is some advantage to filtered results sets there are factorial more who get burned by them. It still also comes down to a fundamental problem when any command in any language can present two differing results without 'notice' of any kind.
>>>
>>>This is true of many things in VFP. How many people get 'burned' because of weak data typing in VFP? I'm sure that forcing us to declare and use strongly typed data would avoid a lot of "Operator/operand type mismatch" errors at runtime, because they could be caught by the compiler before the app crawled out the door. It'd make creating structures less painful because the exact nature of data representation would be clearer at compile time, and we wouldn't have to go through the name table resolution of variables to figure out the size and relative locations of things. OTOH, the things we'd have to give up to convert to strong data typing make this an unattractive alternative, for me at least. YMMV. I'd rather have the things that we gain from weak data typing, like on-the-fly creation of undeclared variables...
>>
>>This (weak typing) has **nothing** to do with the issue at hand. And there is a very large difference between the two issues. Weak typing has always been an inherent characteristic of the language. Two possible differing results, with no notice of one or the other and where subsequent processing is limited on the one hand but not on the other can hardly be called "good design", especially when the documentation barely describes the possible situation.
>>
>
>Actually, filtered cursors have been a way of life in Fox since the 1.02 days where SQL syntax first crawled in the door...is this a case of only some legacy things are worthy of your acknowledgement?
>
>Some Legacy Commands are More Equal Than Others has a rather Orwellian feel to it...