Finally we got OIPI to generate basic reports in PDF with some basic formatting.

But…

it only works, when run from within OI on the server, when trying to run it through a remote engine via OECGI it won't.

What are we doing wrong?

Ver: OI413

Regards

Wilhelm

Wilhelm,

OIPI32 is currently a VB executable that uses the WM_SETTEXT and WM_GETTEXT messages to communicate with OE.

Because OECGI (and therefore OE ) is running in the context of your web-user (probably Anonymous right?), the server's security probably won't allow this type of communication. I believe it's a similar sort of issue that OICGI had, and you may have to alter some security privileges and allow OECGI to interact with the desktop.

The Sprezzatura Group

World leaders in all things RevSoft

Sprezz,

didn't get the whole picture with your explanation:

Any client sends any request through OECGI (we have no problems with other type of requests with any user). Once, the request comes through, an OEngine is started on the server and does it's job, depending on the request.

All other requests work well - OEngine processes and returns the results. Only the request asking to activate OIPI wont't start from a remote engine.

Since this occurs on the server side (past OECGI) why would we need different priviliges?

Wilhelm

Wilhelm,

All other requests work well - OEngine processes and returns the results. Only the request asking to activate OIPI wont't start from a remote engine.

Define "remote". Are these the engines that you are starting on your web-server? What OECGI registry flags are you using?

Since this occurs on the server side (past OECGI) why would we need different priviliges?

When a request is submitted to a web-server it has to determine what the originator of that request is allowed to do, so, in the case of IIS for example, the system creates an anonymous user account to handle anonymous requests. The request is fulfilled within the context of this account which by default is very restricted and usually doesn't include the ability to execute other programs or talk to other processes currently running UNLESS you give it permission to do so.

Anything you try and do *beyond* OECGI.EXE will use this same user context - so if you try and start OIPI which happens to be in a folder where the anonymous user doesn't have any execution rights then OIPI won't execute.

Of course, the problem could be something as simple as not having the correct working directory set when you try and launch OIPI but … :)

Take a look at this thread and this thread for some more ideas.

The Sprezzatura Group

World leaders in all things RevSoft

Sprezz,

our solution is the link you gave to Pascal Landry's post on the error in HANDLE STDCALL.

It works now.

Thanks a lot.

Wilhelm

View this thread on the Works forum...