I've got a process that creates a csv file and then downloads it using DownloadFile. It works on my local machine but when I attempt it on the server it always gets a timeout.

I've checked to make sure the file exists and can be opened. It exists in a folder under the web folder. I've also tried it just in the web folder and that gets a timeout also.

Just for kicks I changed to TransmitFile and it gets the same timeout. All the error logs give me are the timeout errors.

Where else should I look and what else should I try?

How long before it times out?

+++ Rick --

90 seconds.

One solution is send a response to a one moment working page with a refresh callback every ten second (or whatever) and have it check to see if the CSV file exists. When it does just reply with a link to the file.

The CSV file exists within a few milliseconds. I've tried putting in an inkey(2) statement before the Response.DownloadFile and it still times out. I've checked the paths and they are correct. It uses the same variable for the path when it creates the file as it does with it attempts to download.

Not sure what else to try. I guess I could put the VFP IDE on the server and step through it. Didn't want to have to do that.

Only guessing myself but wondering what your ContentType is set to ?

So in testing I'm assuming you can browse to the file by typing in the path and filename into your browser. This would indicate there is not a lock or security issue with the target file.

The ContentType is set to "text/csv".

I can browse to the file and it downloads fine. This also works locally, but not on the server. Just not sure what I'm missing.

Did you check here:

• Configuring Execution Timeout

90 seconds is the default Web Connection Timeout, so I expect that's the one you're hitting.

Are you seeing an IIS Error message or the Web Connection one for your application?

+++ Rick ---

Not that I assume this is the issue but how many bytes is the CSV file?

Have you tried saving a different format and seeing if the problem exists? Say PDF for example... if it was a security issue PDF or TXT might be less restricted getting through a firewall. This would say it is not a server issue as much as something in between that in localhost is allowed.

if it was a security issue PDF or TXT might be less restricted getting through a firewall. This would say it is not a server issue as much as something in between that in localhost is allowed.

This wouldn't wait for 90 seconds to fail - it'd fail immediately.

+++ Rick ---

So I played around a bit with the timeouts, and I can't for the life of me get the IIS/ASP.NET timeout to actually trigger. I set that value really low (5 seconds) then ran a 20 second request and the 20 sec request completed properly.

So it looks like you're hitting the Web Connection request timeout... especially since that is set to the 90 seconds you are running into.

+++ Rick ---

It's definitely the Web Connection timeout.

Here's what's really weird. I installed the VFP IDE and run the server from the command prompt by just running the main program.

In this setup, the file downloads and doesn't timeout. So I can't even step through it to see what is going on.

Could it be a permission issue with the EXE?

-Phil

Here's what I've found.

If I run the server by double-clicking on the exe and have the visual interface, the downloadfile works.

If I run the server as a COM object with no interface loading it from the Admin Page, the downloadfile times out.

That seems to point at an application error that hangs the server.

Make sure to set SYS(2335,0) to let any UI or Fox dialog errors hang the server.

You can set Unattendedcommode=On in the your app.ini file.

+++ Rick ---

I made both of those changes and it started working.

I removed both of the changes and it is still working.

Go figure.

I'm pretty sure you have a security issue where you can't access something and it's failing access to a file or connection which previously was throwing up a FoxPro UI (file open dialog most likely) that was hanging the server.

Check your permissions and Application Pool security to figure out what account your FoxPro server is running under when instantiated with COM, then make sure you have the rights you need in the folders you're accessing data and other files from. Use SYS(0) to log your current account login with wwServer::Trace("Login: " + SYS(0)) as part of your server startup code (although you still need the rights to be able to write in the startup folder too).

+++ Rick ---

I've had things like Go Figure happen to me before too. My guess is you fixed it some paint in the past and one or more of the FXP files was not being regenerated until you added the suggestions Rick had you apply. I've learned when weird stull like this occurs, I delete all the FXP files from my application and all of the Web Connect too. The only one I leave behind is XFRX.fxp (my wwPDF driver).