«

[Apologies for previous half-post: I regularly mistype some kind of key
combo that submits the post]

I have a page on our intranet that is supposed to stream an Excel sheet to
the user. I'm using pretty standard code:

sFilePath = sFileDir & sFilename

Response.AddHeader "content-disposition","attachment; filename=" & sFilePath

' Create your header information
Response.ContentType = "application/x-msexcel"

' Create and configure your object
Set oFStream = Server.CreateObject("ADODB.Stream")
oFStream.Open
oFStream.Type = 1
oFStream.LoadFromFile(sFilePath)

' Stream it to the client
Response.BinaryWrite oFStream.Read

' Cleanup
oFStream.Close
Set oFStream = Nothing

' force the end
Response.End

This works fine on the main server, but not on my development machine (XP
Pro x64). This has all worded in the past, but this is a new machine, and I
can't get it to work since I've moved across. I'm getting a 'File could not
be opened' error message. In the past, I've had this error when I wasn't
pointing at the right place or where the permissions were not configured
correctly.

Currently the IUSR user has R/W access to the whole folder where the XLS
file is (It's actually in the same folder as the ASP page at them moment).
I've also checked that the filename and path are correct in a number of
ways, including using FSO.FileExists() and it it correct.

But I'm still getting this message... Any ideas?

I also stumbled across a suggestion to simple Response.Redirect to the
file - ironically, this 1-line solution works perfectly. I assume there must
be a caveat or downside to using this technique - otherwise everybody would
be using it. Can anyone sged some light on this?

Cheers

Chris

"> Currently the IUSR user has R/W access to the whole folder where the XLS
> file is (It's actually in the same folder as the ASP page at them moment).
> I've also checked that the filename and path are correct in a number of
> ways, including using FSO.FileExists() and it it correct.
>
> But I'm still getting this message... Any ideas?
>

Have you checked the security of the file itself? It may not be inheriting
from the folder?

> I also stumbled across a suggestion to simple Response.Redirect to the
> file - ironically, this 1-line solution works perfectly. I assume there
must
> be a caveat or downside to using this technique - otherwise everybody
would
> be using it. Can anyone sged some light on this?
>

The caveat is that the file needs to be available in the virtual folder
space of the application which means a savvy client can navigate directly to
it. This may not be problem for you. OTH you might want your ASP to
perform some authorisation first.

Anthony.

"Anthony Jones" <> wrote in message
news:...
>
>
> Have you checked the security of the file itself? It may not be
> inheriting
> from the folder?
>

The file *has* inherited the correct permissions from the parent folder.

>
> The caveat is that the file needs to be available in the virtual folder
> space of the application which means a savvy client can navigate directly
> to
> it. This may not be problem for you. OTH you might want your ASP to
> perform some authorisation first.
>

This is not something I'd worry about in this specific instance, but it
would be an issue in some cases, so it's good to be aware of it.

I'd still much prefer to use the streaming method...

Cheers

Chris

Normally it is not the IUSR account that will need permission if your asp
page is streaming data to the client. Typically the security account needing
permission to the file/folder will be either the 'Network Service' acocunt or
'ASP.NET' account. Try giving access to one or both of those accounts.

"CJM" wrote:

>
> "Anthony Jones" <> wrote in message
> news:...
> >
> >
> > Have you checked the security of the file itself? It may not be
> > inheriting
> > from the folder?
> >
>
> The file *has* inherited the correct permissions from the parent folder.
>
> >
> > The caveat is that the file needs to be available in the virtual folder
> > space of the application which means a savvy client can navigate directly
> > to
> > it. This may not be problem for you. OTH you might want your ASP to
> > perform some authorisation first.
> >
>
> This is not something I'd worry about in this specific instance, but it
> would be an issue in some cases, so it's good to be aware of it.
>
> I'd still much prefer to use the streaming method...
>
> Cheers
>
> Chris
>
>
>

>
> I'd still much prefer to use the streaming method...
>

It's slower and uses way more memory but it your files are small enough
shouldn't be too much of a problem.

Anthony.

"Anthony Jones" <> wrote in message
news:...
>
>>
>> I'd still much prefer to use the streaming method...
>>
>
> It's slower and uses way more memory but it your files are small enough
> shouldn't be too much of a problem.
>

But for internet sites, or secure intranet pages, we can have the streamed
content in an area inaccessible to the user... In this case, it's not an
issue, but there are cases that I can think of that would matter...

CJM

CJM wrote:
> [Apologies for previous half-post: I regularly mistype some kind of key
> combo that submits the post]
>
> I have a page on our intranet that is supposed to stream an Excel sheet to
> the user. I'm using pretty standard code:
>
> sFilePath = sFileDir & sFilename
>
> Response.AddHeader "content-disposition","attachment; filename=" & sFilePath
>
> ' Create your header information
> Response.ContentType = "application/x-msexcel"
>
> ' Create and configure your object
> Set oFStream = Server.CreateObject("ADODB.Stream")
> oFStream.Open
> oFStream.Type = 1
> oFStream.LoadFromFile(sFilePath)
>
> ' Stream it to the client
> Response.BinaryWrite oFStream.Read
>
> ' Cleanup
> oFStream.Close
> Set oFStream = Nothing
>
> ' force the end
> Response.End
>
> This works fine on the main server, but not on my development machine (XP
> Pro x64). This has all worded in the past, but this is a new machine, and I
> can't get it to work since I've moved across. I'm getting a 'File could not
> be opened' error message. In the past, I've had this error when I wasn't
> pointing at the right place or where the permissions were not configured
> correctly.

Comment out the response.contenttype and the response.addheader lines,
and you will see your ASP error.

If your ASP is generating errors, it's that message that Excel is
trying to open as an excel file, hence the "file could not be opened"
message.

"CJM" <> wrote in message
news:%...
> [Apologies for previous half-post: I regularly mistype some kind of key
> combo that submits the post]
>
> I have a page on our intranet that is supposed to stream an Excel sheet to
> the user. I'm using pretty standard code:
>
> sFilePath = sFileDir & sFilename
>
> Response.AddHeader "content-disposition","attachment; filename=" &
> sFilePath
>
> ' Create your header information
> Response.ContentType = "application/x-msexcel"
>
> ' Create and configure your object
> Set oFStream = Server.CreateObject("ADODB.Stream")
> oFStream.Open
> oFStream.Type = 1
> oFStream.LoadFromFile(sFilePath)
>
> ' Stream it to the client
> Response.BinaryWrite oFStream.Read
>
> ' Cleanup
> oFStream.Close
> Set oFStream = Nothing
>
> ' force the end
> Response.End
>
> This works fine on the main server, but not on my development machine (XP
> Pro x64). This has all worded in the past, but this is a new machine, and
> I can't get it to work since I've moved across. I'm getting a 'File could
> not be opened' error message. In the past, I've had this error when I
> wasn't pointing at the right place or where the permissions were not
> configured correctly.
>
> Currently the IUSR user has R/W access to the whole folder where the XLS
> file is (It's actually in the same folder as the ASP page at them moment).
> I've also checked that the filename and path are correct in a number of
> ways, including using FSO.FileExists() and it it correct.
>
> But I'm still getting this message... Any ideas?

Is the virtual server or directory set for immediate expiry on your dev
machine? If so that message may be generated by the browser -- one way to
be sure is to set a custom error handler for error 500;100. Another would
be to disable errors in your ASP script.

Isolate the source of the error and go from there. If it's from the client,
it's likely being broken by immediate expiry.


-Mark


> I also stumbled across a suggestion to simple Response.Redirect to the
> file - ironically, this 1-line solution works perfectly. I assume there
> must be a caveat or downside to using this technique - otherwise everybody
> would be using it. Can anyone sged some light on this?
>
> Cheers
>
> Chris
>
>
>