What is BROWSE doing here?

[alvechurchdata]

I've fixed a reporting problem by adding a BROWSE statement. It's a kludge and I want to fix it properly.

There's a query which builds a cursor. I check _TALLY immediately and run the report if any records have been retrieved. This technique works everywhere else in the app but in this one situation I get an error message telling me that field qty can't be found.

Field qty is there in the SQL and it was there when I single-stepped. I put a BROWSE statement immediately before the REPORT FORM to convince myself that field qty was still there in the Exe.

The report now runs.

Take out the one word BROWSE, rebuild the exe, and the report doesn't run.

Put it back in, rebuild the exe, and the report runs.

The client's happy (ish) because their report runs but I'm not happy with the solution. Does anyone have any idea why adding a BROWSE is solving this problem? It's not a timing problem because a MESSAGEBOX or WAIT WINDOW doesn't help.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[bborissov]

If the current control just before you issue a SELECT ... and then REPORT ... is a GRID you can have such a problems. Grid is a veery greedy control ;o)) it always keeps ITS own RecordSource as a current alias. Workaround:
Just before SELECTing and REPORTing try to setfocus() to some other control.

Borislav Borissov

 

[alvechurchdata]

If the current control ... is a GRID you can have such a problems.

Thanks Borislav. I knew that <g> but I'd forgotten. It's happening because the client (blast him) asked me to hot-key the report on F3 rather than having a button. Normally the grid would be losing focus to a "Print" button but this form is nothing but one big grid.

I'm very glad that there's a sensible reason. I was going quietly mad on site last night.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[bborissov]

LOL

Borislav Borissov