What am I doing wrong? 2

[mcamardo]

This is a doublespace program I was creating and I have run into a lot of issues. I am new to the FoxPro language so explenations are great.

Set Talk Off

Store Fcount() To f

Dimension Afldcnt[f]

For i = 1 To f
If (Type('Field(i)') = 'C') == .T.
Store Field(i) To Afldcnt
Else
= Adel(Afldcnt, i)
Endif
Next i

Store Alen(Afldcnt) To a

For x = 1 To a
For recum = 1 To Reccount()
Store Afldcnt[x] To fld2chk
Do While ' '$Allt(&fld2chk)
Repl &fld2chk With Strt(Allt(&fld2chk), ' ', ' ')
Enddo
Next recum
Next x

Set Talk On

Data Processing Services
Advanced Marketing Direct

http://www.amdirect.com

 

[Stella740pl]

Mike Yearwood,

Sorry, I just noticed link in your post dated 16-Dec-05 16:28.

Well, I don't have full access to your article, but I do have access to MSDN site (see this link, for example:

http://msdn.microsoft.com/library/d...l/dgusing_rushmore_to_speed_data_access.asp),

which states clear enough that

"If a potentially optimizable command modifies the index key in the FOR clause, the record set on which Rushmore is operating can become outdated. In this case, you can disable Rushmore to ensure that you have the most current information from the table."

Which is, also clearly, would be the case in each of the code pieces here.
Does your article mention more cases to disable the optimization than MSDN? If so, would you mind to briefly name them here?

And there is one potentially Rushmore-optimizable command in each of them, it's SCAN/SCAN FOR.

TheRambler,
Since we both don't seem to find the thread, I would like to reiterate, that we shouldn't (or rather I don't) take the first paragraph at face value, since the figures in the article itself disprove it.

I find it rather ironical statement that uses a non-scientific TANSTAAFL method to support it; then later in the article actually disproves it with more scientific methods of tests and charts. Don't you find? (Unless you know for which ancient version it was originally written that the opening statement could have been true.)

 

[Stella740pl]

Mike,

A SCAN without any FOR clause is not optimized.
Yes, I know that, that's why I said "potentially".

What I am trying to say is this: even with FOR clause, optimization wouldn't speed up/improve the process. Specifically because of the quoted reason. And even more so when using $ instead of AT(). Disclaimer: should test it yet; maybe later.

Even in that code, once the replace is done, the SCAN FOR does correctly identify the next record. The warning would not apply. It would apply if one of the upcoming records were modified before the record pointer got to that record.
Are you sure about that?
Because the quote from MSDN is preceded by the following paragraph:

When you issue a command that uses Rushmore, Visual FoxPro immediately determines which records match the FOR clause expression. These records are then manipulated by the command.

[i]If a potentially optimizable command modifies the index key in the FOR clause, the record set on which Rushmore is operating can become outdated. In this case, you can disable Rushmore to ensure that you have the most current information from the table.[/i]

Got to pick on one of your previous posts, though (hope you don't mind ).
I doubt you'll find that AT is not optimizable in the help. You can only find what is optimizable.
It states explicitly that $ is not Rushmore-optimizable, though.

 

[TheRambler]

>I find it rather ironical statement that uses a non-scientific TANSTAAFL method to support it
I agree with you, Lauren Clarke was being facetious. He looks very scientific to me, see some of his articles here.

 

[Stella740pl]

One of the things I wish they would not mention as being not optimizable is LOOKUP().Using that function with the 4th parameter is probably one of the fastest SEEKs available...

Maybe it's not optimizable because it's already optimal? :-D
(Cannot say that about $, though.) But that's intriguing news. Thanks. I virtually never use this function. Got to test it, along with the other stuff.