Syntax error in LOCATE command

[Toman]

Hi,

After some work on older project I've received error message "Syntax error" on line with simple LOCATE command working well for ages there.

* This program has no other meaning then to illustrate mentioned syntax error
* It is a fragment of a project, so don't ask why SCATTER, INDEX ON or GO 2 is used here

CREATE table tblPersons (name c(20),category c(10),year c(4))
   INSERT INTO tblPersons VALUES ("Paul A. Samuelson","Economics","1970")
   INSERT INTO tblPersons VALUES ("John Galsworthy","Literature","1932")
   INSERT INTO tblPersons VALUES ("Winston Churchill","Literature","1953")
   INSERT INTO tblPersons VALUES ("Albert Camus","Literature","1957")
   INSERT INTO tblPersons VALUES ("Albert Claude","Medicine","1974")
   INSERT INTO tblPersons VALUES ("Woodrow Wilson","Peace","1919")
   INSERT INTO tblPersons VALUES ("Marie Curie","Physics","1903")
   INSERT INTO tblPersons VALUES ("Niels Bohr","Physics","1922")
   INSERT INTO tblPersons VALUES ("Enrico Fermi","Physics","1938")
   INSERT INTO tblPersons VALUES ("Louis de Broglie","Physics","1929")
   INSERT INTO tblPersons VALUES ("Jaroslav Heyrovsky","Chemistry","1959")
   INDEX ON category TAG category

CREATE table tblRating (category c(10),rating n(2))
   INSERT INTO tblRating VALUES ("Economics",65)
   INSERT INTO tblRating VALUES ("Literature",99)
   INSERT INTO tblRating VALUES ("Medicine",71)
   INSERT INTO tblRating VALUES ("Peace",50)
   INSERT INTO tblRating VALUES ("Physics",1)
   INSERT INTO tblRating VALUES ("Chemistry",90)

GO 2						&& this record might be interesting
SCATTER NAME oUserSel		&& so remember it

SELECT tblPersons

* program will terminate at next statement due to syntax error
[COLOR=red]
LOCATE FOR category = M.oUserSel.category
[/color]
IF FOUND()
	MESSAGEBOX("Found: " + tblPersons.name)
ELSE
	MESSAGEBOX("Not Found")
ENDIF

During sleepless night I have find out, that there are a few ways to eliminate the problem.

- avoid indexing on field which is LOCATEd (comment out line "INDEX ON category TAG category" to see)
- disable using Rushmore optimization (add NOOPTIMIZE clause to LOCATE or SET OPTIMIZE OFF)
- eliminate use of object property in LOCATE statement (substitute it with standard variable MyVar = M.oUserSel.category)
- use SEEK M.oUserSel.category instead

This still doesn't give me an answer to what's going wrong with my LOCATE statement.
Will someone explain it to me? I smell a rat in Rushmore.
Thank you, Tom (VFP 7, SP1)

 

[Olaf Doschke]

Hi Tom,

I can reproduce this error using VFP7 SP1 like you. I'm a bit puzzled too, regarding where the error is located. Another solution I found is

LOCATE FOR category = oUserSel.category

So it should regard rushmore and the memory object m.

But your code works fine in VFP9, so the bug is already known and fixed there.

Bye, Olaf.

 

[Mike Gagnon]

If you are using the SCATTER NAME technique, this creates an object not a memory variable, so you need to reference the fields with oUserSel.category and not assume that there is a memory variable as well.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Toman]

Hi,
From VFP7 help file:

To reference a property in an object that has the same name as an open table, preface the property name with the M. qualifier.

That's my case – sorry for me. I don't do it any more, but in this old project I am talking about, I frequently copied records from tblSomeTable by SCATTER NAME tblSomeTable to have them accessible from the rest of a project.
Thanks, Tom.

 

[Olaf Doschke]

As already said SCATTER NAME does create a memory variable. You can also access it with

? m.oUserSel.category

The bug seems only to have an effect if you use both rushmore optimization and the "m." memory object.

But as Mike Yearwood said, if you have a naming convention that way, that all your tables start with tbl and all your objects start with o, there is no way that an o...category property can be confused with some tbl...category field.

The only reason to use m. then is performance. And if that is your concern, I'd use SEEK anyway instead of LOCATE. Or even LOOKUP or SET RELATION.

Bye, Olaf.