Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Odd Report Behavior

Status
Not open for further replies.

edbytes

Programmer
Aug 29, 2001
27
0
0
US
I have a simple app. One form(1) that calls another form(2) and then has the ability to print a report. Each form uses a single table. Form1 works with a parent table1, which allows you to find an account. Form2 then pulls the account details from a second table2 based on a relation as follows:

&&form1
select table1
set relation ... into table2
&& call form2

If you choose to print the report, a query is run to pull the matching records into a cursor and the report is printed from based on the cursor.

The problem that I'm having has to do with the change of the active table. When I print the report the cursor is created and selected however sometimes I get an error that it can't find one of the fields in the report because the table that is actually selected isn't the report cursor. This is odd because prior to actually issuing the "report form" command I check the currently selected table and it is correct. But once I issue "report form" the selected table is changes to the first table I opened and not the report cursor.

The report data environment is empty and the report NOT running in a private data session. The code to run the report is as follows:

selece *... into cursor myCursor
Select MyCursor
report form ....
use in myCursor


Any ideas or suggestions would be greatly appreciated.
 
Edbytes,

You say: " ... sometimes I get an error .. "

Can you say what is different about the times you get the error? Under what circumstances the error occurs?

The code you posted looks basically correct. The only other thing I can think to check is the expression fields within the report. Do any of these have a preceding alias (e.g. are you referencing "MyTable.ID" rather than just "ID")? That would also apply to things like Print When clauses.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
I say "sometimes" because it is inconsistent. I will print the report and get an error, ignore it, and print it again and it process properly without an error. I have checked the report thoroughly and there is no reference to the table that causes the error.
 
Could it be that within the report you're calling a function that changes the selected table?

Jim
 
Is there a grid on the form, from which you run the report?

If you get the error and can inspect the currently selected alias, is that the recordsource of that gird?

Set the focus to some other control, eg a commad button or a textbox, before printing. Grid controls can be a reason, why suddenly and unexpected the grid recordsource is the selected workarea.

Bye, Olaf.
 
jimstarr - Negative. Only function on report uses a variable reference.

OlafDoschke - Yes there is a grid on the form and it has focus when the report is called. The report is called from a menu choice so maybe I'll try using a command button and see what happens.
 
Edbytes,

Yes there is a grid on the form and it has focus when the report is called.

I'll bet that's the answer.

In some circumstances, when focus is on a grid, the recordsource of the grid becomes the alias for the report. I can't give you any details, but I've definitely seen that behaviour before.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Try it with the Relationship off before you create the Cursor. i.e. Set relationship off then create the cursor. Also, check the alias for the field in the report. I have found relationships in reports are not 100% reliable…
 
Very nice everyone. Looks like the grid focus is the issue. I took the report off of the main app menu option and made it a command button option instead and it printed with no problems. The only question I'm left with now is if I'm calling the report from the app menu why isn't this enough to remove focus from the grid?

Thanks again everyone.
 
What do you mean by calling from the menu? If this would be from toolbar, then toolbars don't receive focus, so the problem persists. I think with menu you have the same problem, the grid still has focus.

I was recently facing the same problem and had to put an invisible button on the form (make it visible right before printing) in order to overcome grid's own mind.
 
Very, Very, Very Strange… We have 3 forms that have grids which provide the user the capability to print detail via a Right Click in a Column (textbox) and have never experienced this behaviour.

Unless I have totally misunderstood the problem, I have to disagree that a grid having a focus will give erratic results in a report. Just to be sure I tested it…

Try This:
Create a form, put a grid with 3 columns. In the Form load, use Northwind Customers and Orders Tables.
For the Grid use customers as recordsource, Customer ID, Company name, Contact Name as columns controlsource.

In the Customer ID column, Textboxs Right Click(),this will ensure the grid has the focus, put the following:

**2 choices here:
cvalue = Customers.customerid
*******either this
*!* Select Orders.*;
*!* FROM ;
*!* northwind!Customers ;
*!* INNER Join northwind!Orders ;
*!* ON Customers.customerid = Orders.customerid;
*!* WHERE Orders.customerid = cvalue ;
*!* INTO Cursor ordcursor

***Or a totally different table
Select Orders.*;
FROM northwind!orders;
INTO Cursor ordcursor

Select ordcursor
Report Form test Preview

Now: create a report call it test:

In the detail band put 3 fields with their expression as
ordcursor.customerid
ordcursor.orderdate
ordcursor.freight

Run the form and right click any Customer ID and the report will preview

What am I doing Right? {s}
VFP9 SP1
 
Did you click Print button from the preview? The problem usually shows up in Print, not in the Preview. Also it is not 100% reproducible, but with 90% probability.
 
Yes i did both in 80 and 90 Engine behavior; But if using the Print Button from the preview pane, the report form command Must say:

Report Form test FOR ordcursor.customerid = cvalue Preview

otherwise all records will print...this is a very very old quark.

It worked because I sub-consciously changed the command before testing. Tried it again with only Report Form… and clicked the Print button and got the whole table (grids record source) with blanksif

Maybe that was the problem... We never caught it as we disable the Print Button
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top