Streaming file to user: 'File could not be opened'

[CJM]

[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.AddHea der "content-disposition","a ttachment; filename=" & sFilePath

' Create your header information
Response.Conten tType = "applicatio n/x-msexcel"

' Create and configure your object
Set oFStream = Server.CreateOb ject("ADODB.Str eam")
oFStream.Open
oFStream.Type = 1
oFStream.LoadFr omFile(sFilePat h)

' Stream it to the client
Response.Binary Write 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.Redire ct 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

[Anthony Jones]

"> 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.Redire ct 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.

[CJM]

"Anthony Jones" <An*@yadayadaya da.com> wrote in message
news:eY******** ******@TK2MSFTN GP10.phx.gbl...

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

[Matt]

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" <An*@yadayadaya da.com> wrote in message
news:eY******** ******@TK2MSFTN GP10.phx.gbl...

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

[Anthony Jones]

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.

[CJM]

"Anthony Jones" <An*@yadayadaya da.com> wrote in message
news:ej******** ******@TK2MSFTN GP11.phx.gbl...

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

[Larry Bud]

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.AddHea der "content-disposition","a ttachment; filename=" & sFilePath

' Create your header information
Response.Conten tType = "applicatio n/x-msexcel"

' Create and configure your object
Set oFStream = Server.CreateOb ject("ADODB.Str eam")
oFStream.Open
oFStream.Type = 1
oFStream.LoadFr omFile(sFilePat h)

' Stream it to the client
Response.Binary Write 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.conten ttype and the response.addhea der 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.

[Mark J. McGinty]

"CJM" <cj*******@news group.nospam> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

[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.AddHea der "content-disposition","a ttachment; filename=" &
sFilePath

' Create your header information
Response.Conten tType = "applicatio n/x-msexcel"

' Create and configure your object
Set oFStream = Server.CreateOb ject("ADODB.Str eam")
oFStream.Open
oFStream.Type = 1
oFStream.LoadFr omFile(sFilePat h)

' Stream it to the client
Response.Binary Write 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.Redire ct 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