Weird Behaviour of VFP 8.0

[vazagothic]

Hello,
I've encountered a weird behaviour of VFP 8.0. I do not know how to explain it, but code which was working just fine under 6.0 no longer performs as it should with the VFP 8.0.

The purpose of the code is to get all unique values from the table (without using SQL SELECT) - it uses the table's index to move between different values.

It jumps to the first occurence of certain value, then moves back one record (to get another unique value), next jumps to the first occurence of this value .. and so on

Here's the code - I've modified it a bit, so it would work as a whole piece:

*** CODE STARTS HERE ***
[red]
scNameFile = "Names_MM"

USE names_MM
SET ORDER TO cty_owner

SELECT (scNameFile)
GO TOP
* Get the first value from table
lcCountyValue = county

* Scan the entire table using INDEX value
DO WHILE .T.
* Show record number (just for TESTING)
? RECNO()
* Scan in the backward order - which finds the last matching value
SEEK lcCountyValue ORDER cty_owner DESCENDING
IF FOUND()
* Add only NON-EMPTY values
IF !EMPTY(lcCountyValue)
? lcCountyValue
ENDIF
SELECT (scNameFile)
* Move to the previous value and remember it
SKIP -1
* Check if current county is the same as the previous one found ..
IF lcCountyValue = county
EXIT
ENDIF
lcCountyValue = county
ELSE
EXIT
ENDIF
ENDDO
[/red]
*** CODE ENDS HERE ***

It seems that VFP 8 no longer follows the index value while using SKIP +/- 1.

The output with VFP6 looks like:
[blue]
8385
7667
MINNEHAHA
9180
ALAMEDA
9158
ALBANY
6247
ARAPAHOE
[/blue]
etc

While the VFP8 leaves the loop just after showing "[blue]8385[/blue]".

How should I modify the above code so it would work fine under VFP8 ?

I should mention that using [red]SELECT DISTINCT county FROM names_mm INTO CURSOR tmp[/red] is quite useless. SQL SELECT takes more than 10 times longer for a table 500k records big, than the method shown above.

 

[vazagothic]

Ok, I believe I found the problem ..
SEEK was changed in the 8.0 (comparing to 6.0)

SEEK in VFP 6.0
[red]
SEEK eExpression
[ORDER nIndexNumber | IDXIndexFileName
| [TAG] TagName [OF CDXFileName]
[ASCENDING | DESCENDING]]
[IN nWorkArea | cTableAlias]
[/red]

SEEK in VFP 8.0
[red]
SEEK(eExpression [, nWorkArea | cTableAlias
[, nIndexNumber | cIDXIndexFileName | cTagName]])
[/red]

Small change to the previous code made it work again ..

[red]
scNameFile = "Names_MM"

USE names_MM
[blue]SET ORDER TO cty_owner DESCENDING[/blue]

SELECT (scNameFile)
[blue]GO BOTTOM[/blue]
* Get the first value from table
lcCountyValue = county

* Scan the entire table using INDEX value
DO WHILE .T.
? RECNO()
* Scan in the backward order - which finds the last matching value
SEEK lcCountyValue
IF FOUND()
* Add only NON-EMPTY values
IF !EMPTY(lcCountyValue)
? lcCountyValue
ENDIF
SELECT (scNameFile)
* Move to the previous value and remember it
SKIP -1
* Check if current county is the same as the previous one found ..
IF lcCountyValue = county
EXIT
ENDIF
lcCountyValue = county
ELSE
EXIT
ENDIF
ENDDO
[/red]

 

[craigber]

SEEK really wasn't changed in 8 compared to 6. You're looking at two different entries, one for the SEEK command and the other for the SEEK function.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[vazagothic]

My fault, I was upset about the not working code and I made a hastly mistake with the help

But it doesn't change the fact, that the code didn't work with VFP8. Only the mentioned change had restored its proper behaviour.

So, what was the cause for VFP8 to stop working ?

 

[Mike Lewis]

Vazagothic,

It seems that VFP 8 no longer follows the index value while using SKIP +/- 1.

Not true. VFP 8.0 behaves just like earlier versions in this respect. In fact, there is nothing in your code that would behave differently in different versions. The fact that you are getting a different result must be due to something different in the environment, like the tables being in different directories or some such.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[vazagothic]

The fact that you are getting a different result must be due to something different in the environment, like the tables being in different directories or some such.

Nope, not really - as far as I've tested, the same table is being used.

I've followed the code with a BROWSE window open and it turned out that after performing the first
[red]SEEK lcCountyValue ORDER cty_owner DESCENDING[/red]
we get two different results in VFP6 and VFP8

In VFP6, the field [blue]county[/blue] looks as follow:
(I've marked the current record with asterisks)
...
AURORA
AURORA
ARAPAHOE
ALBANY
ALAMEDA
"empty county" *****
"empty county"
"empty county"
...

while VFP8 returned the same values in a different order:
...
"empty county"
"empty county"
"empty county" *****
ALAMEDA
ALBANY
ARAPAHOE
AURORA
AURORA
...

And that was the reason why my code didn't perform the requested operations in VFP8 - after SKIP -1 it did go "UP" one record. The [red]county[/red] value didn't change, so it quit the loop.

In VFP6 it was enough to use [red]SEEK lcCountyValue ORDER cty_owner DESCENDING[/red] to change the index order to a descending one, while in VFP8 you have to use [red]SET ORDER TO cty_owner DESCENDING[/red] before you beform the [red]SEEK[/red]

 

[Mike Lewis]

SEEK lcCountyValue ORDER cty_owner DESCENDING

I've just tried this in both 6.0 annd 8.0, and I get identical results in each case. They both work exactly as you would expect. (This was with 8.0 SP1.)

Also, threre is nothing in the Help to suggest that this behaviour has changed.

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[rgbean]

I'd check your settings for SET EXACT and SET NEAR - make sure these are the same in both environments. (The defaults or your code may be changing them.)

Rick

 

[vazagothic]

Both ar OFF.

Here are links to two screenshots of the BROWSE window taken in both VFP8 and VFP6.

They show two different results after performing the same operation on them.

VFP6:

http://gothic.sitenet.pl/vfp6.jpg

VFP8:

http://gothic.sitenet.pl/vfp8.jpg

Any ideas what could have been wrong ?

 

[rob444]

On the examples you've put up you're using dirrerent commands!

On vfp6:
seek "MINNEHAHA" order cty_owner DESCENDING

On vfp8:
seek "MINNEHAHA" order cty_owner

That makes a difference...

Rob.

 

[vazagothic]

Nah,
I did put the same ones The window in VFP8 was cut

I copy&paste the code I've used in VFP8 into VFP6 and run it
from the Command Window, so the code was identical.

 

[rob444]

The only thing I can think of is rebuilding your index(es) and have another try at it.

Rob.

 

[rgbean]

vazagothic,
You didn't answer whether the environments had the same settings. (i.e. NEAR and EXACT in particular!)

Rick

 

[vazagothic]

vazagothic,
You didn't answer whether the environments had the same settings. (i.e. NEAR and EXACT in particular!)

I did answer that (look on the screenshots
In both situations the NEAR and EXACT are OFF

 

[vazagothic]

I've tested in on two different computers, with three different tables - the same result.

Using [red]SEEK ... ORDER ... DESCENDING[/red] gives two different results in VFP6 and VFP8.

In VFP6 the table has the index in a [blue]descending[/blue] order (even without using the [red]SET ORDER TO .. DESCENDING[/red] to start with) but VFP8 requires using [red]SET ORDER TO ... DESCENDING[/red] to work properly.

Without the [blue]DESCENDING[/blue] part in [blue]SET ORDER[/blue], the [red]SEEK ... ORDER ... DESCENDING[/red] was generating normal (ascending order) table.