VFP9 and indexseek issue?

[mkrausnick]

I'm testing my VFP8 app in VFP9 and I have run into a problem I don't understand.

1. I have the following code that fixes invalid IDs in import data (invalid IDs are converted to asterisks in a prior step):

DO WHILE INDEXSEEK("*********",.T.,"import1","ID") 
.
. code that calculates valid ID 
.
REPLACE ID WITH Calculated_ID
ENDDO

The ID field in import1 is c(9), and the ID tag expression is "ID" ascending. The import1 table is created via ZAP followed by APPEND FROM ... TYPE SDF.

What happens is that the do loop runs ok through part invalid IDs and then decides it's done. It varies in different test runs on the same data from processing almost none to processing about 3/4 of them. I stuck a SET STEP ON in the middle of the do loop so I could look at the problem, and of course, it proceeded to process all IDs correctly.

Any ideas? Is there a patch or service pack I don't know about?

Mike Krausnick
Dublin, California

 

[dbMark]

VFP 9 is the most stable version yet with no major issues so far from what I've heard, and there is no service pack yet. Ken Levy said in his blog, "A Service Pack 1 for Visual FoxPro 9.0 would probably release around the end of [2005] based on feedback, reports, etc. A service pack is completely independent of our plans on enhancing Visual FoxPro in the future." Look for the latest on the Visual FoxPro Roadmap in the upcoming June 2005 VFP newsletter at

http:///msdn.com/vfoxpro.

Although I don't see a clear cause, could it be that as you're moving the records around that the order in which the table is SEEKed changes so that some records are skipped? INDEXSEEK() is very powerful but be sure your logic allows for all the order permutations.

From VFP Help: INDEXSEEK( ) returns false (.F.) when you are attempting to find a value in the most recently created record (created with INSERT INTO or APPEND BLANK) until the record pointer is moved. You can execute a GO BOTTOM command to cause INDEXSEEK( ) to find the most recently created record.

 

[VolkerStamme]

Mike,

IndexSeek might simply get confused because you're updating a value you've currently SET an ORDER TO.
You could try SCAN / ENDSCAN instead. It'll also use the index and therefore be v quick. Another option you could try is to put your id calculation into a function and

REPLACE ALL ID WITH yourFunction() FOR ID ='*********'

and don't use any loop at all.

Volker/

 

[Eguy]

mkrausnick,

I whole-heartedly agree with dbMark and Volker. It has been my experience that whenever you change an index value when that index is active, all bets are off. It is sure to come back and bite you in the #%&. Maybe not all the time, but it will eventually.

My $0.02

Ed


Please let me know if the suggestion(s) I provide are helpful to you.
Sometimes you're the windshield... Sometimes you're the bug.

 

[mkrausnick]

Thanks for the responses. I am aware of the fact that when I modify a field that SET ORDER depends on that the file pointer moves along with the change. That's why I use DO WHILE instead of SCAN/ENDSCAN, which I have experienced does NOT work.

I'll try adding a GO TOP inside the loop after modifying the value ala dbMark's post and come back with the result. I'd like to avoid using the REPLACE ... FOR option because the occurance if invalid IDs is small and the import files are large - 10-20K records at a time.

Mike Krausnick
Dublin, California

 

[craigber]

The way I've done ID changes in the past is:

SEEK TheValue
DO WHILE FOUND()
REPLACE OldValue WITH NewValue
SEEK TheValue
ENDDO

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

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

 

[mkrausnick]

Well, I have not been able to reproduce the problem since I recompiled the source in VFP9 after adding the SET STEP ON. It seems to work now the same whether I manipulate the file pointer inside the loop or not. So I'm wondering whether simply running VFP8 code in VFP9 is what caused the problem in the first place. I guess I'll recompile all my source and continue testing.

Mike Krausnick
Dublin, California

 

[mspratt]

Hi Mike,

I'm suprised it worked at all. Although I haven't used it much, my recollection is that INDEXSEEK() doesn't move the record pointer.

Regards,

Mike

 

[dbMark]

INDEXSEEK(eExpression [, lMovePointer [, nWorkArea | cTableAlias [, nIndexNumber | cIDXIndexFileName | cTagName]]])

lMovePointer - Specifies if the record pointer is moved to the matching record. If lMovePointer is true (.T.) and a matching record exists, the record pointer is moved to the matching record. If lMovePointer is true (.T.) and a matching record doesn't exist, the record pointer isn't moved. If lMovePointer is false (.F.) or is omitted, the record pointer isn't moved even if a matching record exists.

This just seeks to see if it's in the index. Only if the optional second parameter is .T. will it move the record pointer.

 

[mspratt]

Ahhh... Thanks Mark.

A way to seek without going to EOF() if the record doesn't exits.

Regards,

Mike