Having taken your advice and experimented with some non FP Ext reliant code,
I have discovered that the solution to this problem almost certainly lies in
the fact that the Session object is not persisting past page re-directions,
(in this case to global.asa) therefore the Session variables, ie the Form
Saved Data arrays, are not persisting either.
This I have proved by extensive use of the debugger tool using test asp
scripts.
This is also provable by creating an asp with the script;
<% response.write(session.sessionid) %>
And viewing in browser, the returned id no. changes on each page refresh,
indicating that the Session is not being sustained.
As I understand Session communication is dependant upon cookies,
I have set Internet Explorer for minimum security and to accept all cookies.
IIS is configured to support Session state, with the default expiry of 20
mins.
In test scripts, substituting Application object variables for Session
object variables works perfectly well, (but with the disadvantage of the
extended scope.)
What other factors determine Session persistence ?
If Session is maintained by IIS, what effects does global.asa have ?
What other configuration parameters need setting to allow Sessions to
survive re-direction ?
Are any other hacks or patches required ?
I hope you can help me solve this problem, if not can you point me to
somewhere for further assistance.
Many thanks, in advance
Ian
--
Ian C
"Egbert Nierop" wrote:
>
> "Ian C" <IanC RemoveThis @discussions.microsoft.com> schreef in bericht
> news:48A14DDB-8B12-48EA-A4AC-9D5E7B37B360@microsoft.com...
> > Hi all,
> >
> > I have already spent hours searching the Knowledge Base and other support
> > sites, without result, so now I hope can help me solve a problem.
> >
> > First some tech. info.
> >
> > I have an Intranet (100BaseTX) System Comprising:
> >
> > System 1:
>
> >
> > The default web site (inetpub\wwwroot) is used in all cases.
> >
> >
> > The problem, common to all combinations of the above intranet, is:
> <snip>
> >
> > It appears that all instances of Web Bot components are being ignored or
> > not
> > parsed correctly.
> >
> > Examination of the Frontpage source code for both the form and custom
> > confirmation form shows all references to Web Bots are in grey, which is
> > the
> > default colour for comments. Is this significant ?
>
> I'm no frontpage fan, and in fact, IIS supports FP 2002, but you are talking
> about a web design problem.
> Maybe you can convert your web bots to .asp pages or aspx pages? That would
> be the most robuste future proof solution.
>
> > The FP Configuration Info as shown in web-site\_vti_inf.html is:
> > FP Version = 5.0.2.6417
> > FPShtmlScriptUrl = _vti_bin/shtml.dll/_vti_rpc
> > FPAuthorScriptUrl =_vti_bin/_vti_aut/author.dll
> > FPAdminScriptUrl=_vti_bin/_vti_adm/admin.dll
> >
> > The version number of these isapi dll files, to be found in virtual
> > directory ‘_vti_bin’ ( Prog Files/Common/MS Shared/web server
> > extensions\50\isapi’, is 10.0.6308 in each case
>
>
> I have 10.0.6754.0 try to update (windows update?)
> But FP ext is no longer supported by MS.
> >> Stay informed about: Frontpage 2002 Confirmation Page problems. 
FAQ
Search
Profile
Private Messages
Log in/Register/Password
