I could have sworn I saw a post from Ed on "SET ORDER TO TO" in VFP7 and how

to fix it but I can't find it in the archive.

This is a real PITA if you are a good typist.

Mr. Jerry Cotton, MCP

PBL-LSS Development Manager

112 Realini Drive

Havelock NC, 28533

mailto:cottonjp@2mawcp.usmc.mil

(252)466-4854 (w) (252)229-0628 (c)

Cotton Jerry P wrote:

> I could have sworn I saw a post from Ed on "SET ORDER TO TO" in VFP7 and how

> to fix it but I can't find it in the archive.

>

> This is a real PITA if you are a good typist.

Go to the Tools/Intellisense Manager menu, and go to the 'Advanced' tab.

Select 'lEnableFullSetDisplay' from the list, and type 'F' in the value

box. This will suppress the 'TO' in any SET command.

___/

/

__/

/

____/

Ed Leafe

http://leafe.com/

I knew I saw that somewhere before.

Thanks Ed.

Mr. Jerry Cotton, MCP

PBL-LSS Development Manager

112 Realini Drive

Havelock NC, 28533

mailto:cottonjp@2mawcp.usmc.mil

(252)466-4854 (w) (252)229-0628 (c)

> -----Original Message-----

> From: Ed Leafe [mailto:ed@leafe.com]

> Sent: Friday, January 26, 2001 1:02 PM

> To: Multiple recipients of ProFox

> Subject: Re: VFP7 Set order to to

>

>

> Cotton Jerry P wrote:

>

> > I could have sworn I saw a post from Ed on "SET ORDER TO

> TO" in VFP7 and how

> > to fix it but I can't find it in the archive.

> >

> > This is a real PITA if you are a good typist.

>

> Go to the Tools/Intellisense Manager menu, and go to

> the 'Advanced' tab.

> Select 'lEnableFullSetDisplay' from the list, and type 'F' in

> the value

> box. This will suppress the 'TO' in any SET command.

>

>

> ___/

> /

> __/

> /

> ____/

> Ed Leafe

> http://leafe.com/

>

>

> ----------------------------------------

> Subscription maintenance at:

> http://leafe.com/mailListMaint.html

>

>

>

Hello. Another developer here just tracked down a bug that is

caused by set("order") returning a full "TAG blah OF c:\blah\blah with

spaces\blah.cdx" instead of just a "TAG blah", as was set with the

original "set order to" command. This is disasterous when you save off

the order, "set order to" to increase data handling performance, and

then try to set it back-- VFP doesn't know how to parse the spaces in

the path(and VFP doesn't quote it from Set("order")), and bombs. I'm

assuming we can parse the output to make it work, but hasn't this been

found before? Anyone have a better work-around? Thanks.

--

Derek

At 2005-12-02 18:07, you wrote:

> Hello. Another developer here just tracked down a bug that is

>caused by set("order") returning a full "TAG blah OF c:\blah\blah with

>spaces\blah.cdx" instead of just a "TAG blah", as was set with the

>original "set order to" command. This is disasterous when you save off

>the order, "set order to" to increase data handling performance, and

>then try to set it back-- VFP doesn't know how to parse the spaces in

>the path(and VFP doesn't quote it from Set("order")), and bombs. I'm

>assuming we can parse the output to make it work, but hasn't this been

>found before? Anyone have a better work-around? Thanks.

Save the numeric value of ORDER() instead.

******************************

* Dan Olsson

* <mailto:dan@dolittle.se>

* <http://www.dolittle.se>

At 12:07 PM 12/2/2005 -0500, Derek Kalweit wrote:

> Hello. Another developer here just tracked down a bug that is

>caused by set("order") returning a full "TAG blah OF c:\blah\blah with

>spaces\blah.cdx" instead of just a "TAG blah", as was set with the

...

>the order, "set order to" to increase data handling performance, and

>then try to set it back-- VFP doesn't know how to parse the spaces in

...

I think you want to use the ORDER() function instead of the SET("ORDER") call.

-Charlie

> > Hello. Another developer here just tracked down a bug that is

> >caused by set("order") returning a full "TAG blah OF c:\blah\blah with

> >spaces\blah.cdx" instead of just a "TAG blah", as was set with the

> >the order, "set order to" to increase data handling performance, and

> >then try to set it back-- VFP doesn't know how to parse the spaces in

> I think you want to use the ORDER() function instead of the SET("ORDER") call.

Thank you Charlie and Dan. I guess that code was written when used to

calling SET() for all the other settings that had to be set back.

Thank god for consistency............

--

Derek

I'm finding code where the developer had done a SET ORDER TO and then SEEK

command afterwards instead of using the SEEK(a,b,c) function with its

parts. I'm not sure when the SEEK(a,b,c) function came to be, so perhaps

this is because it was written prior to that?

IAC, I thought I had heard that doing a SET ORDER TO on a network table

was slow or caused a performance hit, especially since all we want to do

is use the index to check for the existence of a condition that could

nowadays be done with the SEEK(a,b,c) function. While refactoring, should

this be done (...replacing the old SET ORDER plus SEEK command with the

SEEK function instead)?

Just curious...tia!

--Michael

On Sep 11, 2007, at 12:24 PM, Michael J. Babcock, MCP wrote:

> IAC, I thought I had heard that doing a SET ORDER TO on a network

> table

> was slow or caused a performance hit, especially since all we want

> to do

> is use the index to check for the existence of a condition that could

> nowadays be done with the SEEK(a,b,c) function. While refactoring,

> should

> this be done (...replacing the old SET ORDER plus SEEK command with

> the

> SEEK function instead)?

You should know the answer by now: test both versions under actual

network conditions. There is a good chance that the current code is

not noticeably slower than the proposed new code; if so, you've just

saved a bunch of rewriting.

-- Ed Leafe

-- http://leafe.com

-- http://dabodev.com

> > IAC, I thought I had heard that doing a SET ORDER TO on a network

> > table

> > was slow or caused a performance hit, especially since all we want

> > to do

> > is use the index to check for the existence of a condition that could

> > nowadays be done with the SEEK(a,b,c) function. While refactoring,

> > should

> > this be done (...replacing the old SET ORDER plus SEEK command with

> > the SEEK function instead)?

> You should know the answer by now: test both versions under actual

> network conditions. There is a good chance that the current code is

> not noticeably slower than the proposed new code; if so, you've just

> saved a bunch of rewriting.

Generally, with many files(some big, some small), I've noticed

considerable 'scan' speed increases by removing any orders set on the

cursor with 'set order to'.

I personally doubt there would be a significant speed difference

between SEEK() and SET ORDER TO...SEEK itself, but if the ORDER is

left set on the file and subsequent record pointer changes are done,

it could slow things down-- but be very careful about removing the SET

ORDER TO's, as that order could be critical to the logic of the code

itself...

--

Derek