Questions about SCAN....ENDSCAN

[xBaseDude]

Maybe not question, just asking for confirmation.

When one runs a SCAN on a DBF, the process begins from the "top" of the table.

IOW, it is ridiculous to.....

LOCATE FOR [Abashed Goat] $ cItem
SCAN
<some code>
ENDSCAN

The &quot;LOCATE FOR&quot; is superflous, as the pointer will move to the top of the table, and begin processing there, once the SCAN command executes.

*****

SCAN will follow the index order (if an order has been set), instead of the &quot;natural order&quot; or the table.

ie SET ORDER TO cCity, SCAN will begin at the &quot;lowest&quot; value of cCity...[Aaronsberg]...instead of the first record entered in the table.

TIA and Regards - Wayne

 

[JRB-Bldr]

The command SCAN / ENDSCAN may have a Scope defined.

With nothing designated, the Default is for All records, but you can use:

SCAN NEXT nnn
SCAN REST
SCAN FOR xxxxx
etc.

So you could use your
LOCATE FOR [Abashed Goat] $ cItem
IF FOUND()
SCAN REST
<some code>
ENDSCAN
ENDIF

There are other ways to accomplish similar tasks, some of which might work better (i.e. faster), but Yes you could use the SCAN.

And, Yes, SCAN will follow the active Index order.

Good Luck,
jrbbldr
jrbbldr@yahoo.com

 

[FoxProProgrammer]

In addition to your points, the LOCATE command is normally used to find a record in an unindexed table. Normally you would use a SEEK to find a record in an indexed table because it takes advantage of the Rushmore technology to speed up searches. This is especially useful in large databases. As you pointed out, SCAN/ENDSCAN provide a convenient way to execute a sequence of commands, and FoxPro automatically increments the record pointer when it gets to the ENDSCAN. It saves the programmer from incrementing the record pointer when you want to execute the same commands on a range of records. Both commands are useful in certain applications, and not mutually exclusive.

dz

 

[Jerry4DOS]

Seems to me I remember that SCAN...ENDSCAN works faster on an UNORDERED table -- might be useful if you're going to SCAN an entire table.

 

[rgbean]

Jerry,
That's certainly true if you plan on processing the whole table, but if you can use a SEEK() to get to a specific record and then do a SCAN WHILE ... on that index order then this will reduce the number of records needed to be processed and will likely overcome any &quot;penalty&quot; for traversing the table in an index order.

Rick

 

[xBaseDude]

Thanx for responding guys!

jrbbldr [REST]!!! Thanx for that! That really helps me out.

I use LOCATE instead of SEEK as I am processing a relatively small result set in a QUERY table. Although I have been able to create indexes on QUERY's, IMHO I find the LOCATE works better for me. Speed lose on a <500 record table on a 350MHZ machine is negligible.

I would like to discuss on another thread the concept of creating indexes on queries.

Regards Gents - Wayne

 

[DSummZZZ]

By the way, LOCATE is Rushmore-able too.

Dave S.

 

[Eguy]

Dave,

Is Rushmoreable a real word or did you just make that up?

Anyway, any single table command using the FOR clause is Rush... Rush... (what you said).

My $0.02
Ed Please let me know if the sugestion(s) I provide are helpful to you.
Sometimes you're the windshield... Sometimes you're the bug.

 

[DSummZZZ]

It is now. B'yuk. If I can invent the internet, I can make up words too.

Dave S.

 

[Guest_imported]

Whow i can use disckspace() function for more than 2 giga
byte space?

 

[DSummZZZ]

You should start a new thread for this, but what are you asking? Could you be more specific?

Dave S.

 

[DSummZZZ]

Never mind. You already did. It's been a while since I was in here.

Dave S.

 

[StewartJ]

SCAN WHILE has a default scope of REST, so

= SEEK(****)
SCAN WHILE <field> = ****
*
*
ENDSCAN

will take you to the first record of interest and drop you out as soon as you have processed the last one (assuming that you have the correct index order set!).

 

[xBaseDude]

True or False?

Never put a SCAN...ENDSCAN with-in a SCAN....ENDSCAN

ie...

SELE mydbf
SCAN
<STUFF>
SELE another_dbf
SCAN
<STUFF>
ENDSCAN
SELE mydbf
ENDSCAN

is *bad* coding...Why?

TIA - Wayne