Are you certain it's a problem when the report is exported and not something else? If it were failing to export the report, you should get an error message at the point where it does the export.

Please add the "-debug" option to the command line and make sure you have it producing a log file (more information) so we can see exactly what's going on.

If you are using the "-removefile" option then the export always goes to a subdirectory under the user's TEMP folder. There's no way to change this other to change the user's temp folder (by setting the TEMP environment variable) before you run Report Commander. But so as long as the user has permissions (create files and folders, read, and write) on their own TEMP folder there shouldn't be a permission issue.

If you're not using that option it will write it to the path specified in the "-exportfile" option.

Our customer is pretty unhappy with the process at this point, may be difficult to get logs from them.  I'll try to recreate locally as we've had this problem with a few of our Enterprise customers that use Active Directory and I probably have a VM somewhere to test.

 

Looking at the command line that our script generates, I see -exportformat=PDF -removefile

 

So if I alter our script to remove the -removefile option and specifiy an export path, perhaps we could test emailing from a different folder?

 

 

You gave an error message initially. Is that not coming from the log file (or capturing the screen output)? There should be an earlier message in the same output telling you about what the problem is, even without the debug option turned on.

If you take off the "-removefile" option then you need to include a path and filename in the "-exportfile" option and that's where the report will be exported to (and emailed from). The file will be left there when Report Commander finishes.

It has been quite a trip to just get to a point where I can get a useful log, our customer's server is incredibly restricted and there were numerous issues to workaround to get to this point.  

I added some options so that I could pass a custom directory for it to write the output to and so that I could add -debug to the logging and received the below message.  We're using a python script to get all the database info, download the .rpt file and call Report Commander.  If I run the python script, I get the error.  If I run Report Commander Command Line Builder with the same parameters (or as close to as I can), it does work mostly okay.

2021-09-27 23:00:41 Debug Exporting report to C:\Program Files (x86)\ReportQueuePython\~326524715c724e9c9ae9de417a1ce00a.pdf
2021-09-27 23:00:53 Error Export failed: The system cannot find the path specified.
Exception detail: System.Runtime.InteropServices.COMException (0x80004005): The system cannot find the path specified.

   at CrystalDecisions.ReportAppServer.Controllers.ReportSourceClass.Export(ExportOptions pExportOptions, RequestContext pRequestContext)
   at CrystalDecisions.ReportSource.EromReportSourceBase.ExportToStream(ExportRequestContext reqContext)
   at CrystalDecisions.CrystalReports.Engine.FormatEngine.ExportToStream(ExportRequestContext reqContext)
   at CrystalDecisions.CrystalReports.Engine.FormatEngine.Export(ExportRequestContext reqContext)
   at CrystalDecisions.CrystalReports.Engine.ReportDocument.Export(ExportOptions options)
   at #Lwd.#Kwd.#Ck(#Rvd , FileOutput )
2021-09-27 23:00:53 Info Sending e-mail for task Send e-mail with subject "Sales Order"
2021-09-27 23:00:53 Warning E-mail task Send e-mail with subject "Sales Order" is configured to attach an output that was not produced (Sales Order : Output Group 1 : Export). The e-mail message cannot be sent.

The error "The system cannot find the path specified" comes from the Crystal Reports runtime and is generally misleading. It's probably not referring to the output file at all, but could indicate a problem with database driver setup, ODBC alias configuration, or report design. See this article for more information.

If it were a permission problem I think you would get an "Access denied" error instead. Make sure "C:\Program Files (x86)\ReportQueuePython" because Report Commander won't create it if it doesn't.

Since you can get the same report to run outside of your Python script it's probably not a database driver installation problem or report design problem, so that leaves something in permissions or system configuration that differs between when you run it directly and when you run it from the Python script.

When you run the export yourself from the command line, are you logged in under the same account that the Python script runs under? If not, try that and see if you get the error. Also, if the report uses ODBC to connect to the data source, make sure the ODBC alias is either defined as a System alias or is defined correctly for the user account that runs the script.

If you're not using ODBC, let me know what you are using, and if there's anything configurable for the driver make sure it's configured the same for both user accounts (if relevant). For example if it's Oracle, make sure that all the configuration and required environment variables are correct for the account you're running the script from.

If none of this leads anywhere, the best thing to do is use Process Monitor to trace what's going on in the data access layer and see if that gives any clues (such as permission problems or an actual "Path not found" while trying to read or write from the filesystem. You can save the log to PML format and open a support case to send it to us for review if nothing leaps out at you. It sounds like this may be difficult for you to pursue if the customer's computer is locked down but there's really nothing else we can look at to trace the problem--the error comes from functionality outside our control