<br><br><div class="gmail_quote">On Wed, Mar 19, 2008 at 11:35 AM, Nancy Palmquist <<a href="mailto:nlp@vss3.com">nlp@vss3.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">Tyler wrote:<br>
> Just in case anyone's still interested in my fpcgi saga, here's an update.<br>
><br>
> Adding an entry to the submitted forms for the nohtmlreturn field didn't<br>
> resolve the issue. There were minor bomb outs (meaning the filepro<br>
> processing didn't run and no output was produced) throughout testing,<br>
> but after about 5 days it stopped outputting anything for any report.<br>
><br>
> Working with fptech on the issue, so may have more to follow up with<br>
> after speaking with them.<br>
></div></div></blockquote><div><br>Thanks for the suggestions, Nancy! Let me address some of the things you've brought up.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have to say that you are giving fpCGI too much credit. All it does is act as<br>
a go-between. It grabs form data send via POST or GET methods and writes it to<br>
a file and then it executes a filePro application passing the name of that data<br>
file, which is responsible to grab the data via an IMPORT of some kind. Process<br>
the data and generate output.<br>
<br>
The output is then dragged back to the Browser that made the request.<br>
<br>
It should be very easy to verify if the filePro application ran and generated<br>
output.<br>
<br>
If it did, it must be where and what the fpCGI was told it would be.</blockquote><div><br>While the form data file IS being created, fpCGI is either not running the filepro application correctly, or rreport is bombing out before it can execute even a single command. This is on a test box with no other users or processes running, btw - all that is happening is fpcgi testing.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, you can tell it to leave the IMPORT file so you can test or see what you<br>
got from the form submit.<br>
<br>
Field_removeflat=NO<br>
<br>
Since you keep saying you are getting no output, I would suggest that the<br>
filePro part is not running correctly.</blockquote><div><br>That does appear to be the case. However it is NOT the processing table bombing out, as it is the *same* processing table running with the *same* data on every single test run. Since rreport continues to run other processing with no problem after this issue appears, and running the same processing at the command line that fpcgi is failing to run and having it work just fine, I am forced to assume that it is fpcgi's way of running rreport that is faulty.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">add some lines to do the following:<br>
<br>
putenv "LOGFILE", "Somefilename"<br>
logtext @td<@tm<"Starting my file"<br>
<br>
add a few logtext commands at critical places. I might write the filename I<br>
will be generating, put one at the every end - put one at the very beginning.<br>
See what it posts.</blockquote><div><br>As I posted earlier, one of the processing tables being run by fpcgi and failing is pretty much exactly that - three lines that create a text file with just the word 'running' in it. There is no output.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think Mark's suggestion that onegate would solve your problem is wrong, it<br>
will give you different errors and recovery capabilities. If you are getting<br>
filePro errors, or not generating any output, or reading the input file<br>
incorrectly, you will have the same issue with onegate.</blockquote><div> <br>I would agree that OneGate is not the solution. Sorry, Mark!<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I use them both. They both work. Issues with your report generation sounds<br>
like where the problem can be found.</blockquote><div><br>I really don't think report generation is the issue, for the reasons outlined above, and neither does the person we're working with at fptech. I appreciate the input, tho! Always good to get other insights and plans of attack on the problem, which is why I am posting this in the first place! :D<br>
<br>Tyler <br></div><div><br><br><br></div></div><br>