>>The REPORT FORM command is not supported in VFP multi-threaded(MT) COM dlls. It's supported in single-threaded (ST) dlls in case of object-assisted reporting (REPORTBEHAVIOR=90). It's supported in COM EXE for any REPORTBEHAVIOR.
>
>Really? I checked the docs and it wasn't listed as one of the disabled commands (I thought the initial reason pre-VFP 9 reports didn't work in anything except an EXE was because there wasn't any way of disabling the UI but that with object assisted reports that should go away). I'd be happy to switch over to an EXE com object, but I can't get the dang thing to work at all on our server (works OK on my machine thought) even after messing around in DCOMCNFG.

Yes It's documented in VFP9 help:
REPORT FORM and LABEL commands are no longer automatically prohibited as user-interface-related commands in COM objects compiled into DLLs, when you run the commands in object-assisted mode. The restriction still applies to these commands when they are run in backward-compatible mode. (The topic Selecting Process Types explains why user-interface-related commands are prohibited in DLLs.) This change is not applicable to multi-threaded DLLs. A number of user-interface-related facilities also are not available in DLLs (whether single- or multi-threaded). For example, the TXTWIDTH( ) Function and TextWidth Method depend on a window handle to function, so they are not available in a DLL. The CREATE REPORT - Quick Report Command relies on the same facilities as TXTWIDTH(), and therefore is not available in a DLL. However, in many instances, creating custom output using a ReportListener does not require any user-interface activity, so a REPORT FORM or LABEL command can now be used productively in a DLL. Using the SYS(2335) - Unattended Server Mode function to trap for potential modal states, as well as the new SET TABLEPROMPT Command, is recommended. Refer to Server Design Considerations and Limitations for more information.