ASP App Hangs.

[Richard Gutery]

G'day. Slight problem that has me perplexed.

We have an ASP app running on Win2K IIS 5.1, devloped on WinXPpro.

Up until the other day, the app worked without problems.

Now, the app hangs on an FSO request. I've inlcuded the relevant code below
for referrence.

Basically, the code will check to see if a dir exists (CALLOUT 1), then
checks Write permissions by trying to create
a test.txt file (CALLOUT 2), then deletes the file created in CALLOUT 3. The
uploadsDirVar points to another disk
volume and has the correct permissions (NTFS) assigned and have not changed
(see CALLOUT 3 below):

This code is thisASP file called from the site's Default.asp.

CODE SNIPPET START:
Dim fso, fileName, testFile, streamTest

(CALLOUT 1)
' TestEnvironment is a function that simply returns a string with an error
or is = to "" if no error.
TestEnvironment = ""
Set fso = Server.CreateObject("Scripting.FileSystemObject")
if not fso.FolderExists(uploadsDirVar) then
'Folder does not exist
TestEnvironment = "ERROR NO: 900 (Account Error [f] )! Contact the Office
for Assistance."
exit function
end if

' The next series try to Create and Delete a dummy file. If we cannot, then
we have a Permissions error
fileName = uploadsDirVar & "\test.txt"
on error resume next

(CALLOUT 2 - THIS IS WHERE THE APP HANGS UNTIL!)
Set testFile = fso.CreateTextFile(fileName, true)

(from here on out, everything works fine).
If Err.Number<>0 then
' No Write Permissions
TestEnvironment = "ERROR NO: 901 (Account Error [w] )! Contact the Office
for Assistance"
exit function
end if

(CALLOUT 3)
Err.Clear
' This works, so the NTFS perms are good to go!
testFile.Close fso.DeleteFile(fileName)
CODE SNIPPET END:

The dir exists and nothing has changed in terms of permissions, dir
locations or Code. No errors are returned from the Browser, Server or App.
It just hangs. Nothing in the Event Logs (Auditing turned on and shows no
errors either).

If I terminate the app (via the browser) I cannot use the app again.What I
mean to say is that when I try to connect to the app via default.asp,
everything just hangs.

If we debug the app and comment out the lines at CALLOUT 2 (between the If
and Endif) all works fine.if I create test.txt in Explorer, comment out
CALLOUT 2 and execute the app, CALLOUT 3 will delete the file, so we know
that IUSR_machine has the correct permissions which suggest that the server,
app and code are all good.

Any Ideas???

Richard

[Bob Barrows [MVP]]

Richard Gutery wrote:

G'day. Slight problem that has me perplexed.

We have an ASP app running on Win2K IIS 5.1, devloped on WinXPpro.

Up until the other day, the app worked without problems.

Now, the app hangs on an FSO request. I've inlcuded the relevant code
below for referrence.

http://www.aspfaq.com/show.asp?id=2180

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Richard Gutery]

Thanks for the link Bob. My bad, I should have mentioned that I disabled
"Script Blocking in NAV". Note to self, include more information in future
postings!

Interestingly enough, I just hit a client web site (where I have this code
in production) and all worked well (with and without NAV blocking scripts on
my laptop). I suppose one of my questions would be: Why would NAV script
blocking (client side) affect Server Side ASP? I can see this when I run the
site on my lapatop, but on a dev server that is in my computer room.

So as an experiement, I pulled my clients code down, put it on my dev server
and the same thing is happening.

Hmmm?

btw: On my dev server, I've disabled NAV Corporate Edition altogether,
double checked the perms (mirrored exactly as my client's server) and nada.

R.

"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Richard Gutery wrote:

G'day. Slight problem that has me perplexed.

We have an ASP app running on Win2K IIS 5.1, devloped on WinXPpro.

Up until the other day, the app worked without problems.

Now, the app hangs on an FSO request. I've inlcuded the relevant code
below for referrence.

http://www.aspfaq.com/show.asp?id=2180

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Richard Gutery]

Problem solved! It was actually a reply from Bob Barrows that got me going
on this - thanks Bob.

It seems that when you disable Script Blocking in NAV (actually SYM
Systemworks 2005) and you reboot after a Live Update, Systemworks will reset
any options that you've turned off to the values chosen at "Install Time".
For NAV Corporate Edition on a Server, script blocking is enabled
automatically for all Managed Clients and when the client logs in the NAV
client manager re-enables what ever features you've configured for "Managed
Clients"!

I guess the "Rule of thumb would be": Always double check NAV settings after
Live Updates or nAV Corp Edition Updates to managed clients.

I disables Script Blocking and all is well.

R.

"Richard Gutery" <rg*****@mentorits.com> wrote in message
news:Oa**************@TK2MSFTNGP14.phx.gbl...

G'day. Slight problem that has me perplexed.

We have an ASP app running on Win2K IIS 5.1, devloped on WinXPpro.

Up until the other day, the app worked without problems.

Now, the app hangs on an FSO request. I've inlcuded the relevant code
below for referrence.

Basically, the code will check to see if a dir exists (CALLOUT 1), then
checks Write permissions by trying to create
a test.txt file (CALLOUT 2), then deletes the file created in CALLOUT 3.
The uploadsDirVar points to another disk
volume and has the correct permissions (NTFS) assigned and have not
changed (see CALLOUT 3 below):

This code is thisASP file called from the site's Default.asp.

CODE SNIPPET START:
Dim fso, fileName, testFile, streamTest

(CALLOUT 1)
' TestEnvironment is a function that simply returns a string with an error
or is = to "" if no error.
TestEnvironment = ""
Set fso = Server.CreateObject("Scripting.FileSystemObject")
if not fso.FolderExists(uploadsDirVar) then
'Folder does not exist
TestEnvironment = "ERROR NO: 900 (Account Error [f] )! Contact the
Office for Assistance."
exit function
end if

' The next series try to Create and Delete a dummy file. If we cannot,
then we have a Permissions error
fileName = uploadsDirVar & "\test.txt"
on error resume next

(CALLOUT 2 - THIS IS WHERE THE APP HANGS UNTIL!)
Set testFile = fso.CreateTextFile(fileName, true)

(from here on out, everything works fine).
If Err.Number<>0 then
' No Write Permissions
TestEnvironment = "ERROR NO: 901 (Account Error [w] )! Contact the
Office for Assistance"
exit function
end if

(CALLOUT 3)
Err.Clear
' This works, so the NTFS perms are good to go!
testFile.Close fso.DeleteFile(fileName)
CODE SNIPPET END:

The dir exists and nothing has changed in terms of permissions, dir
locations or Code. No errors are returned from the Browser, Server or App.
It just hangs. Nothing in the Event Logs (Auditing turned on and shows no
errors either).

If I terminate the app (via the browser) I cannot use the app again.What I
mean to say is that when I try to connect to the app via default.asp,
everything just hangs.

If we debug the app and comment out the lines at CALLOUT 2 (between the If
and Endif) all works fine.if I create test.txt in Explorer, comment out
CALLOUT 2 and execute the app, CALLOUT 3 will delete the file, so we know
that IUSR_machine has the correct permissions which suggest that the
server, app and code are all good.

Any Ideas???

Richard

[Stefan Berglund]

On Sun, 9 Jan 2005 12:21:34 -0700, "Richard Gutery"
<rg*****@mentorits.com> wrote:
in <Or**************@TK2MSFTNGP10.phx.gbl>

Problem solved! It was actually a reply from Bob Barrows that got me going
on this - thanks Bob.

It seems that when you disable Script Blocking in NAV (actually SYM
Systemworks 2005) and you reboot after a Live Update, Systemworks will reset
any options that you've turned off to the values chosen at "Install Time".
For NAV Corporate Edition on a Server, script blocking is enabled
automatically for all Managed Clients and when the client logs in the NAV
client manager re-enables what ever features you've configured for "Managed
Clients"!

I guess the "Rule of thumb would be": Always double check NAV settings after
Live Updates or nAV Corp Edition Updates to managed clients.

A better rule of thumb might be to use a better Anti Virus.
---
Stefan Berglund

[Richard Gutery]

Good Point.

"Stefan Berglund" <ke****@in.thegroups> wrote in message
news:he********************************@4ax.com...

On Sun, 9 Jan 2005 12:21:34 -0700, "Richard Gutery"
<rg*****@mentorits.com> wrote:
in <Or**************@TK2MSFTNGP10.phx.gbl>

Problem solved! It was actually a reply from Bob Barrows that got me going
on this - thanks Bob.

It seems that when you disable Script Blocking in NAV (actually SYM
Systemworks 2005) and you reboot after a Live Update, Systemworks will
reset
any options that you've turned off to the values chosen at "Install Time".
For NAV Corporate Edition on a Server, script blocking is enabled
automatically for all Managed Clients and when the client logs in the NAV
client manager re-enables what ever features you've configured for
"Managed
Clients"!

I guess the "Rule of thumb would be": Always double check NAV settings
after
Live Updates or nAV Corp Edition Updates to managed clients.

A better rule of thumb might be to use a better Anti Virus.
---
Stefan Berglund