Sorry for the delay. I was out of town and out of touch for a while. Basically, the work-around is to write the .pdf to a folder accessible to the web server and redirect the browser to the file instead of streaming the return. The approach has a few benefits. Aside from getting around this bug, it prevents a strange phenominon where the server gets hit 2 or 3 times (depending on the browser version) to retrieve the file. According to the Microsoft KB, this is by design. The first hit signals that a plug-in will be used and the second hit retrieves the data. Too bad since our application has already begun streaming it on the first hit! In any case, it requires some way to clean up the temp files since they must be left on the disk for a while. I call ADIR() on each new report and erase any files over an hour old, but some folks just make it part of their nightly backup routine.

Many of us have found that when we redirect to the PDF, the browser displays only a white screen. Pressing the back button or the refresh button make it display. I found a work-around for this that seems pretty clean so far. I process the report via an ASP page that calls a VFP COM .EXE to create the PDF. The ASP page sends back an HTML page with nothing on it that times out and redirects to the PDF file instantly using this header:

Response.AddHeader "REFRESH", "0;URL=" & cReturn

So far, so good, the report shows up in every IE and Netscape version I've tested, from every IIS server I've got. The overhead of the empty page to create the redirection isn't even noticable on a slow dial-up.

Hope that helps you,
Mike