Charlie,

It may not have been clear in the prior reply to you that I *DO* accept the current observations being reported for VFP. It is that they seem to have been the same in FPx that I question.

Cheers,

Jim N

>Hi Charlie,
>
>I agree that I too would be extremely surprised if FP 2.6 was affected by subsequent installs of VFP.
>
>BUT. . . I am even more surprised that we are **now** getting reports of behaviour that differs not only markedly, but also assails one of the basic tenets of FP/VFP until around now (namely that an index on DELETED() is always a good thing). I see this new situation as declaring suddenly that the world is *flat* after all!
>
>I must admit that I was also surprised that both the FPA article writer and yourself chose to confirm similar processing in the FPx versions of the product. It seemed an odd thing to do. But even more odd is the tendancy to accept the observed behaviour as having been there all along. Would it not be much more logical to question this even further given the "history" surrounding this issue???
>
>It is this sudden 'reversal' of the situation that prompts me to question the current assertions (that it seems to have been this way all along). To me the history clashes with this. So I now look for causes that can lead to such observations.
>
>I know extremely little about Windows. But one thing I do know is that, whenever I install virtually anything, some (and often lots) of the programs (DLLs and the like) of the common Windows directories get replaced by newer versions. While not highly plausible, WHAT IF FP/VFP's "Rushmore" or even the SQL "engine" is coded in this manner. That could mean that behaviours in such areas would appear to be consistent when, in fact, they might not have been.
>
>In summary, the history is so strong and so definitive that current observations/conclusions may not be accurate.
>
>Regards,
>
>Jim N
>
>>Jim,
>>I want a better understanding, so no apology accepted. I caught the drift from your earlier message, but didn't follow it up. The answer is no. I haven't run from a machine were VFP was not installed, but I guess I could very easily. I assume you must want to assure yourself that the VFP installs haven't changed anything about the way FPD 2.6 works.
>>I don't see how it could. FoxProX.EXE is totally unaware of Windows NT and thinks it's DOS. It doesn't know about the registry, and the registry doesn't know about it. I don't see how NT even knows FoxProX from Clipper or dBase III. I guess memory allocation could be affected, but you'd think we would see more evidence in plain old execution speed if that were a factor. But...we happen to have some machines that have never seen a Fox, so I will see if there is a difference.
>>In reading an earlier thread, JVP said he showed an example in his classes that showed the positive impact of the DelTag. I will send an E-mail to get the scenario. Certainly, a DelTag lets you BROWSE FOR DELETED() very well, and it allows SYS(3054) to write "Fully not Partially Optimized", but I don't think that was its only purpose.
>>
>>>Hi Charlie,
>>>
>>>Apologizing for my persistence here, but you say "and it apparently has for years".
>>>My guess is that this is based on testing you just did using FP 2.6. I really would like to know if this FP 2.6 test was done on a system *never* touched by any other version of VFP.
>>>
>>>I have outlined WHY I feel this is crucial, but add to it that, for literally years now the "common wisdom" has alweays been to make an index on DELETED(). In fact the Hacker's Guide tells people to do exactly this 'never mind the actual occurrences of deleted records in a table'.
>>>
>>>So I think it is *NOT* reasonable to state that things have apparently been this way for years. To me it definitely has the feel of something "broken", and recently too.
>>>
>>>I am glad that you will submit it to MS.
>>>
>>>Jim N
>>>
>>>>Lance,
>>>>I think this is something MS could/should fix. I will try to send this scenario to them.
>>>>
>>>>If you SEEK(Expr, Alias, TagName) with a SET ORDER TO AnyTag, it's fast--even across the WAN. Again, my testing just assumes if there is much network traffic and the table(s) I'm using are accessed through the WAN connection, anything faster than 2 seconds means there was a minimum of packets. If any unusual traffic occurs, we quickly get minutes of elapsed time, not seconds. GO RecNum with SET ORDER TO SomeTag or without, SET DELTED ON/OFF, DelTag in place or not, makes no real difference. All is fast. I just tested GO TOP and GO BOTTOM with all options DELETED ON/OFF ORDERED, and found all of them to be fast. LOCATE with no condition was fast, unless the table has a DelTag and SET DELETED is ON--which makes sense.
>>>>
>>>>The main point is LOCATE when an ORDER is SET reads the index file unnecessarily, and it apparently has for years. I guess the answer for now is--don't do that.
>>>>Charlie
>>>>
>>>>>
>>>>>Another thing to consider is that this was all going on over a fairly heavily used network to begin with and the NT Workstation and even the server weren't running on particularly zippy hardware.
>>>>>
>>>>>I couldn't believe they found it acceptable and didn't call me. If I hand't gone on site I never would have found this problem. They would just start a query and go on break, so they actually were rather fond of my software. :)