Hi Randy;

According to all your comments, I see the following:

dxdt was a global variable, with a reference in the report (was it m.dxdt or just dxdt?)

The report form will only blow up if reaches a point where a variable or reference is evaluated. Thus, if you have sections where, based on the data, a variable won't get written out, the report may work fine until it tries to display that variable. So, you may have a reference that doesn't display when you run it, but does try when your clients do (But not the page header, that will always get run!).

One thing you can do is still keep the dxdt variable around (with some bogus data in it) so the reports don't bomb, but your clients may complain about the data. For those who get the 'bad' data, you can then debug from there.

Is your cursor defined in more than one place? Do all definitions now include that new field?

Is the correct FRX FRT being used? are they compiled into the APP or do they exist seperately on the disk? That is, can yu be sure the report that is running is the one that should be running?

Look for the simplest place for a problem to exist and that's likely where you'll find it!


>the cursor should be selected. there are numerous fields in the report based off the cursor; however, dxdt is in the page header (it refers to a date), so it will be referenced first. I know I select the cursor before I do the report form command, but since it doesn't occur on my machine I can't be for certain that the clients machine is looking at the same cursor, especially since the error doesn't occur every time they run the report. I probably need to clarify what I said earlier too. Dxdt was a variable in the procedure that called the report. We had to capture that variable in the report cursor because we had to create another executable program that runs the reports (for flexibility from client to client, they want to see different results). Maybe this will shed some light.