By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,836 Members | 2,023 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,836 IT Pros & Developers. It's quick & easy.

cookie not sent with window.open

P: n/a
I link to a web site from an Excel spreadsheet. The page i link to is
getCookie.asp which sets a cookie then returns back some html which opens a
new window, to the same site but a different page (same folder).

The cookie is not received. Can someone explain why?

I worked around this by adding a cache-control header with a value of
no-cache. This fixes the problem. Unfortunately that causes another
problem with Internet Explorer that no-one can figure out (basically with
friendly error messages turned on IE shows an error page for no reason - i
posted a lengthy message about this to m.p.i.asp.general but no-one has a
clue).

I have tried every combination of every cache busting header i can think of
but no other one fixes this problem about the cookie not being received.

So basically i'm in a catch-22. If i put the cache-buster in then users
will get a nasty error message from IE unless they have 'friendly' error
messages off. If i leave out cache-buster code then the session cookie
doesn't get returned which means the users cant access my site. Help!

Example asp's are below. To recreate the problem simply create a hyperlink
to getCookie.asp in excel then open it (after each attempt you need to shut
down Excel). By the way everything works fine if you type the URL into IE
directly... the problem is when opening from Excel.

Thanks in advance

Paul

----getCookie.asp------
<%
'cache code which makes next page work
'Response.CacheControl = "no-cache"
'send cookie back to client
Response.Cookies("PaulSessionID") = "PaulsCookie"
%>
<HTML>
<HEAD>
<SCRIPT>
window.open('useCookie.asp','newWin','resizable,sc rollbars,menubar,toolbar')
;
</SCRIPT>
</HEAD>
<BODY>&nbsp;</BODY>
</HTML>
------------------------
-----useCookie.asp------
<%Response.CacheControl = "no-cache"%>
The cookie set by the previous page is:
"<%=Request.Cookies("PaulSessionID")%>"
---------------------------
Jul 19 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a

First, I find it very odd that any kind of caching header would have
anything to do with cookies not being recieved.
The two are completely unrelated AFAIK.

Anyway, I'm trying to grasp what you are doing here, so if I'm getting this
right this is what happens:
- a user has an excel sheet open with a hyperlink in it to getCookie.asp
- the user clicks this hyperlink, which opens a new Internet Explorer
window, loading getCookie.asp
- getCookie.asp sets a cookie, then returns some HTML & JavaScript to open a
new window calling useCookie.asp
- useCookie.asp retrieves the cookie set by getCookie.asp, and uses it
(duh!)

the first thing that I can think of is that that second browser window is
running a new browser session, making it impossible for that window to
retrieve that session-based cookie set by the first window,
I'm not sure that is the case, cause I'm not sure if using window.open() can
cause a new browser session to be created, by I do know for sure this can be
the case if you open a new window by right-clicking, and opening a page in a
new window

IE has/had some setting where each new IE window runs as a seperate
application, which also caused session cookies to "get lost" (they don't
really, cause it's a new session).

A funny session bug I ran into in IE 5 is when you start IE and your
homepage is not a website (file:// protocol instead of http), also causes
your session to get lost when a new window is openened using window.open().

maybe this helps?

"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
I link to a web site from an Excel spreadsheet. The page i link to is
getCookie.asp which sets a cookie then returns back some html which opens a new window, to the same site but a different page (same folder).

The cookie is not received. Can someone explain why?

I worked around this by adding a cache-control header with a value of
no-cache. This fixes the problem. Unfortunately that causes another
problem with Internet Explorer that no-one can figure out (basically with
friendly error messages turned on IE shows an error page for no reason - i
posted a lengthy message about this to m.p.i.asp.general but no-one has a
clue).

I have tried every combination of every cache busting header i can think of but no other one fixes this problem about the cookie not being received.

So basically i'm in a catch-22. If i put the cache-buster in then users
will get a nasty error message from IE unless they have 'friendly' error
messages off. If i leave out cache-buster code then the session cookie
doesn't get returned which means the users cant access my site. Help!

Example asp's are below. To recreate the problem simply create a hyperlink to getCookie.asp in excel then open it (after each attempt you need to shut down Excel). By the way everything works fine if you type the URL into IE
directly... the problem is when opening from Excel.

Thanks in advance

Paul

----getCookie.asp------
<%
'cache code which makes next page work
'Response.CacheControl = "no-cache"
'send cookie back to client
Response.Cookies("PaulSessionID") = "PaulsCookie"
%>
<HTML>
<HEAD>
<SCRIPT>
window.open('useCookie.asp','newWin','resizable,sc rollbars,menubar,toolbar') ;
</SCRIPT>
</HEAD>
<BODY>&nbsp;</BODY>
</HTML>
------------------------
-----useCookie.asp------
<%Response.CacheControl = "no-cache"%>
The cookie set by the previous page is:
"<%=Request.Cookies("PaulSessionID")%>"
---------------------------

Jul 19 '05 #2

P: n/a
J. Baute wrote on 18 mrt 2004 in microsoft.public.inetserver.asp.general:
the first thing that I can think of is that that second browser window is
running a new browser session, making it impossible for that window to
retrieve that session-based cookie set by the first window,


The test of the pudding should be the [temporarily] giving a expiration
date to the cookie, so the cookie is session independent, as long as the
two files are in the same domain.

Even better:

test with 2 cookies at once,
giving only one an expiration date in 2020,
and also with a session variable.

If the session cookie [the one without expiration date] and the session
variable return empty, you know what the problem is.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jul 19 '05 #3

P: n/a
J. Baute wrote:
First, I find it very odd that any kind of caching header would have
anything to do with cookies not being recieved.
The two are completely unrelated AFAIK.
I know... tell me about it!!!
Anyway, I'm trying to grasp what you are doing here, so if I'm
getting this right this is what happens:
- a user has an excel sheet open with a hyperlink in it to
getCookie.asp
- the user clicks this hyperlink, which opens a new Internet Explorer
window, loading getCookie.asp
- getCookie.asp sets a cookie, then returns some HTML & JavaScript to
open a new window calling useCookie.asp
- useCookie.asp retrieves the cookie set by getCookie.asp, and uses
it (duh!)
Correct, this is exactly what i'm trying to do.
the first thing that I can think of is that that second browser
window is running a new browser session, making it impossible for
that window to retrieve that session-based cookie set by the first
window, I'm not sure that is the case, cause I'm not sure if using
window.open() can cause a new browser session to be created, by I do
know for sure this can be the case if you open a new window by
right-clicking, and opening a page in a new window
IE has/had some setting where each new IE window runs as a seperate
application, which also caused session cookies to "get lost" (they
don't really, cause it's a new session).
Yes going back a bit now i've looked into how IE (and different versions of
it) shares its memory between instances of itself.
That's a really good hypothesis... unfortunately i've just checked it out
and it isn't the cause.
A funny session bug I ran into in IE 5 is when you start IE and your
homepage is not a website (file:// protocol instead of http), also
causes your session to get lost when a new window is openened using
window.open().

maybe this helps?
Nope... tried all combinations of home page and its still the same.

Have you (anyone?!?) not managed to reproduce this issue? I've tried it on
at least computers, some inside the office some outside, either w2k or NT4.
The issue is always there.

I'm starting to think its a symptom of a security update related to
window.open. But it can't be... because if it was then the cookie would
*never* be sent, would it!
"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
I link to a web site from an Excel spreadsheet. The page i link to
is getCookie.asp which sets a cookie then returns back some html
which opens a new window, to the same site but a different page
(same folder).

The cookie is not received. Can someone explain why?

I worked around this by adding a cache-control header with a value of
no-cache. This fixes the problem. Unfortunately that causes another
problem with Internet Explorer that no-one can figure out (basically
with friendly error messages turned on IE shows an error page for no
reason - i posted a lengthy message about this to m.p.i.asp.general
but no-one has a clue).

I have tried every combination of every cache busting header i can
think of but no other one fixes this problem about the cookie not
being received.

So basically i'm in a catch-22. If i put the cache-buster in then
users will get a nasty error message from IE unless they have
'friendly' error messages off. If i leave out cache-buster code
then the session cookie doesn't get returned which means the users
cant access my site. Help!

Example asp's are below. To recreate the problem simply create a
hyperlink to getCookie.asp in excel then open it (after each attempt
you need to shut down Excel). By the way everything works fine if
you type the URL into IE directly... the problem is when opening
from Excel.

Thanks in advance

Paul

----getCookie.asp------
<%
'cache code which makes next page work
'Response.CacheControl = "no-cache"
'send cookie back to client
Response.Cookies("PaulSessionID") = "PaulsCookie"
%>
<HTML>
<HEAD>
<SCRIPT>

window.open('useCookie.asp','newWin','resizable,sc rollbars,menubar,toolbar')
;
</SCRIPT>
</HEAD>
<BODY>&nbsp;</BODY>
</HTML>
------------------------
-----useCookie.asp------
The cookie set by the previous page is:
"<%=Request.Cookies("PaulSessionID")%>"
---------------------------


Jul 19 '05 #4

P: n/a
Evertjan. wrote:
J. Baute wrote on 18 mrt 2004 in
microsoft.public.inetserver.asp.general:
the first thing that I can think of is that that second browser
window is running a new browser session, making it impossible for
that window to retrieve that session-based cookie set by the first
window,


The test of the pudding should be the [temporarily] giving a
expiration date to the cookie, so the cookie is session independent,
as long as the two files are in the same domain.

Even better:

test with 2 cookies at once,
giving only one an expiration date in 2020,
and also with a session variable.

If the session cookie [the one without expiration date] and the
session variable return empty, you know what the problem is.


I just did this. What happens is the cookie with the date does get sent.
The cookie without the date (as before) does not.

What does this tell me?

Paul
Jul 19 '05 #5

P: n/a
Paul wrote on 18 mrt 2004 in microsoft.public.inetserver.asp.general:
I just did this. What happens is the cookie with the date does get sent.
The cookie without the date (as before) does not.

What does this tell me?


That both windows are not in the same session.

You could prove this with a session variable as I suggested.

==================

But why not add a expiration of say one hour,
and everyone [with cookes allowed] will be happy?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Jul 19 '05 #6

P: n/a
Evertjan. wrote:
Paul wrote on 18 mrt 2004 in microsoft.public.inetserver.asp.general:
I just did this. What happens is the cookie with the date does get
sent. The cookie without the date (as before) does not.

What does this tell me?


That both windows are not in the same session.

You could prove this with a session variable as I suggested.


Ok cool, so i know that window.open is creating a new session.
Is this:
a) a bug?
b) a feature?!
or c) by design?
Jul 19 '05 #7

P: n/a
"Paul" wrote:

Ok cool, so i know that window.open is creating a new session.
Is this:
a) a bug?
b) a feature?!
or c) by design?


You forgot:
d) unreliable
e) all of the above

Since IE 5.01, the "open new windows in a separate process" option has been
taken out of the user's hands and has been made the responsibility of IE.
IE, for its part, decides whether to do so based on the resources available
to it.

I have demonstrated for many people that this behavior can be changed by
running more (or fewer) applications on the client machine. It is so fickle
as to render session variables useless in our business environment.
--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 19 '05 #8

P: n/a

"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
Evertjan. wrote:
Paul wrote on 18 mrt 2004 in microsoft.public.inetserver.asp.general:
I just did this. What happens is the cookie with the date does get
sent. The cookie without the date (as before) does not.

What does this tell me?


That both windows are not in the same session.

You could prove this with a session variable as I suggested.


Ok cool, so i know that window.open is creating a new session.
Is this:
a) a bug?
b) a feature?!
or c) by design?


The only KB I can find explaining this bug is this one:
http://www.kbalertz.com/Feedback_315713.aspx

I'm thinking it might have something to do with with the original window
starting from Excel as well, since you didn't get that problem when you
loaded the original URL straight from IE.


Jul 19 '05 #9

P: n/a
I've seen this behavior before but I cannot duplicate it any more.

What I have seen in the past is that if the link to the ASP page was
embedded in an HTML pages that was launched from the file system instead of
through the web-server then the browser would not pass the session cookie to
windows opened with window.open().

What version of IE are you using? I have IE 6 with all the latest patches.

--
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com
"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
J. Baute wrote:
First, I find it very odd that any kind of caching header would have
anything to do with cookies not being recieved.
The two are completely unrelated AFAIK.
I know... tell me about it!!!
Anyway, I'm trying to grasp what you are doing here, so if I'm
getting this right this is what happens:
- a user has an excel sheet open with a hyperlink in it to
getCookie.asp
- the user clicks this hyperlink, which opens a new Internet Explorer
window, loading getCookie.asp
- getCookie.asp sets a cookie, then returns some HTML & JavaScript to
open a new window calling useCookie.asp
- useCookie.asp retrieves the cookie set by getCookie.asp, and uses
it (duh!)


Correct, this is exactly what i'm trying to do.
the first thing that I can think of is that that second browser
window is running a new browser session, making it impossible for
that window to retrieve that session-based cookie set by the first
window, I'm not sure that is the case, cause I'm not sure if using
window.open() can cause a new browser session to be created, by I do
know for sure this can be the case if you open a new window by
right-clicking, and opening a page in a new window
IE has/had some setting where each new IE window runs as a seperate
application, which also caused session cookies to "get lost" (they
don't really, cause it's a new session).


Yes going back a bit now i've looked into how IE (and different versions

of it) shares its memory between instances of itself.
That's a really good hypothesis... unfortunately i've just checked it out
and it isn't the cause.
A funny session bug I ran into in IE 5 is when you start IE and your
homepage is not a website (file:// protocol instead of http), also
causes your session to get lost when a new window is openened using
window.open().

maybe this helps?
Nope... tried all combinations of home page and its still the same.

Have you (anyone?!?) not managed to reproduce this issue? I've tried it

on at least computers, some inside the office some outside, either w2k or NT4. The issue is always there.

I'm starting to think its a symptom of a security update related to
window.open. But it can't be... because if it was then the cookie would
*never* be sent, would it!
"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
I link to a web site from an Excel spreadsheet. The page i link to
is getCookie.asp which sets a cookie then returns back some html
which opens a new window, to the same site but a different page
(same folder).

The cookie is not received. Can someone explain why?

I worked around this by adding a cache-control header with a value of
no-cache. This fixes the problem. Unfortunately that causes another
problem with Internet Explorer that no-one can figure out (basically
with friendly error messages turned on IE shows an error page for no
reason - i posted a lengthy message about this to m.p.i.asp.general
but no-one has a clue).

I have tried every combination of every cache busting header i can
think of but no other one fixes this problem about the cookie not
being received.

So basically i'm in a catch-22. If i put the cache-buster in then
users will get a nasty error message from IE unless they have
'friendly' error messages off. If i leave out cache-buster code
then the session cookie doesn't get returned which means the users
cant access my site. Help!

Example asp's are below. To recreate the problem simply create a
hyperlink to getCookie.asp in excel then open it (after each attempt
you need to shut down Excel). By the way everything works fine if
you type the URL into IE directly... the problem is when opening
from Excel.

Thanks in advance

Paul

----getCookie.asp------
<%
'cache code which makes next page work
'Response.CacheControl = "no-cache"
'send cookie back to client
Response.Cookies("PaulSessionID") = "PaulsCookie"
%>
<HTML>
<HEAD>
<SCRIPT>

window.open('useCookie.asp','newWin','resizable,sc rollbars,menubar,toolbar')
;
</SCRIPT>
</HEAD>
<BODY>&nbsp;</BODY>
</HTML>
------------------------
-----useCookie.asp------
The cookie set by the previous page is:
"<%=Request.Cookies("PaulSessionID")%>"
---------------------------


Jul 19 '05 #10

P: n/a
Mark Schupp wrote:
I've seen this behavior before but I cannot duplicate it any more.

What I have seen in the past is that if the link to the ASP page was
embedded in an HTML pages that was launched from the file system
instead of through the web-server then the browser would not pass the
session cookie to windows opened with window.open().

What version of IE are you using? I have IE 6 with all the latest
patches.


Me too. These days its hard to find a machine that doesn't have all the
latest patches! Its a shame that what windowsupdate tells you can't be
totally relied upon; e.g. the other week for Internet banking i had to
install Q831167 which for some reason windowsupdate hadnt previously
installed.

I'd like to have a collection of bootable CD's each one with a different
OS/Brower on, that i could use for testing weird stuff like this. Even if
it was possible (assuming it isnt) the i'm sure licensing cost would be
horrific!!

Paul
Jul 19 '05 #11

P: n/a
J. Baute wrote:
"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
Ok cool, so i know that window.open is creating a new session.
Is this:
a) a bug?
b) a feature?!
or c) by design?
The only KB I can find explaining this bug is this one:
http://www.kbalertz.com/Feedback_315713.aspx


Yep i found this but disregarded it as its file:// although there's
probably some link in there, especially considering that bug you found to do
with file:// homepages.
I'm thinking it might have something to do with with the original
window starting from Excel as well, since you didn't get that problem
when you loaded the original URL straight from IE.


I checked and its actually the same behaviour opening links from Word and
Powerpoint.
Jul 19 '05 #12

P: n/a
Dave Anderson wrote:
"Paul" wrote:

Ok cool, so i know that window.open is creating a new session.
Is this:
a) a bug?
b) a feature?!
or c) by design?


You forgot:
d) unreliable
e) all of the above

Since IE 5.01, the "open new windows in a separate process" option
has been taken out of the user's hands and has been made the
responsibility of IE. IE, for its part, decides whether to do so
based on the resources available to it.

I have demonstrated for many people that this behavior can be changed
by running more (or fewer) applications on the client machine. It is
so fickle as to render session variables useless in our business
environment.


Amazing. Well, thats it then isn't it. I'm done for. I'll have to figure
out a workaround... one that doesn't involve adding the no-cache header that
(for some still unknown reason) fixes it. Maybe some code that interrogates
what window.opener is, to see if its an Office app or an IE window that
itself was spawned by an Office app.

btw How did you demonstrate this behaviour? Did you find a combination of
apps to load or system resources to use up that would make it happen?
Jul 19 '05 #13

P: n/a
We use separate partitions with different OS's for testing and select the
desired environment from the NT boot menu.

If you can afford and MSDN Enterprise or Universal subscription then you get
test licenses for just about everything MS sells (seems like there used to
be a developer program that provided test licenses as well).

--
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com
"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
Mark Schupp wrote:
I've seen this behavior before but I cannot duplicate it any more.

What I have seen in the past is that if the link to the ASP page was
embedded in an HTML pages that was launched from the file system
instead of through the web-server then the browser would not pass the
session cookie to windows opened with window.open().

What version of IE are you using? I have IE 6 with all the latest
patches.


Me too. These days its hard to find a machine that doesn't have all the
latest patches! Its a shame that what windowsupdate tells you can't be
totally relied upon; e.g. the other week for Internet banking i had to
install Q831167 which for some reason windowsupdate hadnt previously
installed.

I'd like to have a collection of bootable CD's each one with a different
OS/Brower on, that i could use for testing weird stuff like this. Even if
it was possible (assuming it isnt) the i'm sure licensing cost would be
horrific!!

Paul

Jul 19 '05 #14

P: n/a
In article <c3*************@ID-141222.news.uni-berlin.de>,
"Paul" <re***************************@hotmail.com> wrote:

Amazing. Well, thats it then isn't it. I'm done for. I'll have to figure
out a workaround... one that doesn't involve adding the no-cache header that
(for some still unknown reason) fixes it. Maybe some code that interrogates
what window.opener is, to see if its an Office app or an IE window that
itself was spawned by an Office app.

btw How did you demonstrate this behaviour? Did you find a combination of
apps to load or system resources to use up that would make it happen?


You tired a possible one it seems. Set a timer on the cookie. Figure
out the worst case time and double it!

In a similiar situation, I used an hour. Depending on your situation,
the called window's javascript code can delete the cookie so you don't
have to worry about it hanging around.

You can also pass data via the search parameter. Do not know if it fits
you situation. See:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Loops</TITLE>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<SCRIPT type="text/javascript">

function foo()
{
var theData, newWindow, URLstring;

// Pass this data. I believe the data is limitted to a max
// of 2k.
theData = "?data=" + escape("see if the caller gets this.");
URLstring = "tryRead.html" + theData;
newWindow = window.open(URLstring,"Printable",
"statusbar,menubar,resizable,toolbar,height=600,wi dth=800");
newWindow.focus();
}

</script>

</HEAD>
<BODY onload='
alert("before.");
foo();
alert("after.");'>

<br><br>Lets open a window and pass data to the window.

</BODY>

</HTML>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Read passed data</TITLE>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<SCRIPT type="text/javascript">

function foo2()
{
var theData;
var begin;

begin = location.search.indexOf("data=");
if (begin >0 )
{

theData = location.search.substring(begin+5,location.search. length);
theData = unescape(theData);
alert("theData = " + theData);
}
}
</script>

</HEAD>
<BODY onload="foo2()">

<br><br>Read passed data.

</BODY>

</HTML>
Jul 19 '05 #15

P: n/a

"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
Amazing. Well, thats it then isn't it. I'm done for. I'll have to figure out a workaround... one that doesn't involve adding the no-cache header that (for some still unknown reason) fixes it. Maybe some code that interrogates what window.opener is, to see if its an Office app or an IE window that
itself was spawned by an Office app.


How about passing that ID as a querystring when you call window.open() ?


Jul 19 '05 #16

P: n/a
Yep there is always the partitions way of doing it, its just a bit 'messy'
for me!

I didn't know that you got licences like that with MSDN... i'll look into
it, thanks

Mark Schupp wrote:
We use separate partitions with different OS's for testing and select
the desired environment from the NT boot menu.

If you can afford and MSDN Enterprise or Universal subscription then
you get test licenses for just about everything MS sells (seems like
there used to be a developer program that provided test licenses as
well).

"Paul" <re***************************@hotmail.com> wrote in message
I'd like to have a collection of bootable CD's each one with a
different OS/Brower on, that i could use for testing weird stuff
like this. Even if it was possible (assuming it isnt) the i'm sure
licensing cost would be horrific!!

Paul

Jul 19 '05 #17

P: n/a
"Paul" <re***************************@hotmail.com> wrote in message
news:c3*************@ID-141222.news.uni-berlin.de...
Yep there is always the partitions way of doing it, its just a bit 'messy'
for me!

I didn't know that you got licences like that with MSDN... i'll look into
it, thanks

Mark Schupp wrote:
We use separate partitions with different OS's for testing and select
the desired environment from the NT boot menu.

If you can afford and MSDN Enterprise or Universal subscription then
you get test licenses for just about everything MS sells (seems like
there used to be a developer program that provided test licenses as
well).

"Paul" <re***************************@hotmail.com> wrote in message
I'd like to have a collection of bootable CD's each one with a
different OS/Brower on, that i could use for testing weird stuff
like this. Even if it was possible (assuming it isnt) the i'm sure
licensing cost would be horrific!!

Paul


The MSDN Universal subscription here in Norway cost NOK 22 000.-, that is
approx. US$ 3 200.- for one year.

This gives every deveoper in your company full access to just about every
piece of software microsoft owns, including localized versions

And MSDN. All software are updated on CD/DVD 4 times a year, in addition to
access to the MSDN subscriber download area online.

--
Dag.
Jul 19 '05 #18

P: n/a
"Paul" wrote:

btw How did you demonstrate this behaviour? Did you find a
combination of apps to load or system resources to use up
that would make it happen?


As I have said, it is unreliable, so it's nearly impossible to schedule a
demonstration. But on several occasions I have shown users who were
experiencing session loss that putting a different resource load on their
systems solved the problem. This was typically done by running more (or
fewer) apps.

And that's just stupid.
--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Jul 19 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.