Weird Report Issue - Variable Not Found

[crewchiefpro6]

I have a weird report issue that I have not seen before. In Fox 9.0 I run a report that works fine when run from the command window. It will also work perfectly in the application until the 2nd page where it will say Variable xxx Not Found. The name of the so called variable is actually a field name.

There is a variable defined to count records, but that is it.

I break on a field called iYear and normally it pops up with an error Variable iYear not found.

Just for fun I put the statement:
iYear = 2006
just before the report form command and it got rid of the message for that "variable" BUT it then said Variable Stocknum Not found. Stocknum is also a field in the driving database.

Weird thing is when I run it by selecting the code in the menu it works just fine, no errors at all.

Here is my simple code:
local lcSelect
lcSelect = select()

IF USED("invrey")
SELECT invrey
USE
ENDIF
SELECT 0
USE data\invrey EXCLUSIVE

INDEX ON STR(9999 - iYEAR,4) + imodel TAG yearmod ADDITIVE
SET ORDER to tag yearmod

REPORT FORM reports\invrey.frx FOR UPPER(invrey.inewused) = "U" AND iyear > 0 preview

DELETE TAG all

SELECT((lcSelect))

Don Higgins

http://www.crewchiefpro.com

 

[crewchiefpro6]

As a follow up when I run it with set step on it works perfectly in the application. The database is correctly listed also. Take Step off and it says Variable iYear is not found.

Other strange thing is when an error occurs it seems to close the database. The next line after the report form is Delete Tag All and another error pops up saying Database Must be Opened Exclusive.

Don Higgins

http://www.crewchiefpro.com

 

[JRB-Bldr]

I might suggest that you put a SET STEP ON just before your REPORT FORM line.

Then run the code in a less interactive mode, but from within your Development environment -- something like DO Test.PRG

Then when the TRACE window activates it will allow you to examine which data table is selected. And you can use the DEBUG window to examine the variable values.

Additionally with the program suspended, you can now use the Command window to MODIFY REPORT and then do a View Preview which will will display the errors encountered.

Good Luck,
JRB-Bldr

 

[crewchiefpro6]

I rewrote the code so I could use a cursor (thanks Ken) and it still has the same errors.

If I use set step on there is NO errors. If I run it from a prg it works perfectly. The only time it has a problem is when I run it in the App. There are NO variables in the report now, no public or private variables, and only one local variable called lcSelect.


LOCAL lcSelect
lcSelect = select()


DO openit IN main WITH "data\invrey"

SELECT * FROM invrey ;
WHERE inewused = "U" ;
.and. iyear > 0 ;
INTO CURSOR lCurInvRey ;
ORDER BY iYear DESC, ;
iModel ASC

REPORT FORM reports\inv2.frx preview


SELECT((lcSelect))

** All Finished
RETURN .t.

Don Higgins

http://www.crewchiefpro.com

 

[crewchiefpro6]

OK, here is some additional information. If a form is running that also uses the same table in a data environment it will bomb.

Does that help with the Variable Not Found issue?

I need this table in the form I am using.

Don Higgins

http://www.crewchiefpro.com

 

[crewchiefpro6]

Now if I take the exact same code, place it on a cmd button on the form, it works perfectly. It refuses to run from the menu.

So I decided to create a new menu with nothing but one print option and the report bombs with the same Variable not found.

If the form is not running the menu works just fine.

The original code has been running fine since 1986, my first year in business. Now he decides to upgrade after years of badgering him, and I would like to deliver this simple upgrade.



Don Higgins

http://www.crewchiefpro.com

 

[Mike Lewis]

Don,

It sounds very much like the wrong table or cursor was selected while the report was running. Maybe a table is being opened AGAIN, with a different alias from the one you were expecting. Or maybe something somewhere forced a different work area to be selected.

I've seen a similar behaviour, where a certain grid was in focus when the report was launched. Setting focus to a grid could cause the grid's alias to be selected, which would cause the type of errors you saw. I'm not saying that's the case here, but it does show how tricky these things are to debug.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[crewchiefpro6]

It runs perfectly when I am in the report designer and choose Print Preview. As I said, the only thing that is different is the form. During debug the recordsource was correct.


I gave up on this, I moved the code to a drop down list box that has the choices on it just like the menu did, with exactly the same code and it runs perfectly.

Thanks for your help, really appreciate the tips from all.



Don Higgins

http://www.crewchiefpro.com

 

[teresas]

I gave up on this

But you have me curious. Do you have any tables in the data environment of the report? Do your field expressions contain table/alias names?

Teresa

 

[crewchiefpro6]

there are no tables in the Data Environment. It is run from a cursor.

There are no field expressions that contain table or alias names preceeding the name.

Since I can run it from the form with a drop down list box my customers are happy enough. Never understood what I did wrong trying to run it from the menu on top however...

Don


Don Higgins

http://www.crewchiefpro.com

 

[gaelin]

Did you try explicitly calling the field by use of an alias? In the report, change the field name from iYear to curTable.iYear.

 

[crewchiefpro6]

Since I call the same report from different cursors and tables I did not want to preface the field with a table name.


Don Higgins

http://www.crewchiefpro.com

 

[gaelin]

Why should that cause a problem? You could just use the cursor or table again and use an alias that point.

 

[crewchiefpro6]

I set up all my reports the same way, no other reason than consitancy. I never had a problem before or after except this one report.

Doesn't matter, it works fine calling it from a form so I am happy and I consider the problem solved.



Don Higgins

http://www.crewchiefpro.com