Have published a web to a 2002 server, initially with FP2K, and now also wit
h
FP03.  There are several components that do not appear to work correctly, eg
:

1) Have many forms, all of which had worked at one time.  All but one work
on the new installation (including forms in subwebs etc). However one form o
n
returns a "partial" email response on "submit".  That is, it essentially onl
y
sends (approx) half of the fieldnames and fieldvalues that have been selecte
d
in the save fields dialog.  Sometimes, the fieldvalues have what appear to b
e
html tag snippets.  There are approx 60 fields/values saved (most are
checkboxes), and only about 30 are returned.  Deleting field from the  form
improves the result, and essentially all fields are obtained when about 30
are deleted.  Though there is still some weirdness in that sometimes there i
s
"blank" inserted into the fieldnames.

How is it possible to get the full form returned (as it was possible before)
?

2) The FP counters will not accept an "overwrite".  E.g. in component
properties there is a field wherein to update the current counter values, an
d
altering this has no effect on the server side.  Nor does the server care if
there is direct editing of the cnt file on the client side.  Eventually
forced overwrite with ftp upload of cnt files, but ???

3) The update Date in the bottom border does not update (on the server side,
but does on the client side) when the body of a page is edited.  However,
when the bottom border is edited (e.g. add a space) then it updates the
server as well, though now globally all pages' dates are brute force
overwritten.

Is it possible that all of these issues are FP extension related?  Does it
make any difference that the site was produced originally in FP2K but is now
under FP03?

[ Post a follow-up to this message ]

Inline below

--
Ron Symonds   (Microsoft MVP - FrontPage)
Reply only to group - emails will be deleted unread.


"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com...
> Have published a web to a 2002 server, initially with FP2K, and now also
> with
> FP03.  There are several components that do not appear to work correctly,
> eg:
>
> 1) Have many forms, all of which had worked at one time.  All but one work
> on the new installation (including forms in subwebs etc). However one form
> on
> returns a "partial" email response on "submit".  That is, it essentially
> only
> sends (approx) half of the fieldnames and fieldvalues that have been
> selected
> in the save fields dialog.  Sometimes, the fieldvalues have what appear to
> be
> html tag snippets.  There are approx 60 fields/values saved (most are
> checkboxes), and only about 30 are returned.  Deleting field from the
> form
> improves the result, and essentially all fields are obtained when about 30
> are deleted.  Though there is still some weirdness in that sometimes there
> is
> "blank" inserted into the fieldnames.
>
> How is it possible to get the full form returned (as it was possible
> before)?

If the email is not formatted as "formatted text" it is possible that some
fields will not be included in the email.  Formatted Text usually sends the
entire form.

>
> 2) The FP counters will not accept an "overwrite".  E.g. in component
> properties there is a field wherein to update the current counter values,
> and
> altering this has no effect on the server side.  Nor does the server care
> if
> there is direct editing of the cnt file on the client side.  Eventually
> forced overwrite with ftp upload of cnt files, but ???

The local copy of the .cnt files are not normally published.  If they were
the counters on the server would be reset with every publish.  Open the web
on the server and update the counter properties there.

>
> 3) The update Date in the bottom border does not update (on the server
> side,
> but does on the client side) when the body of a page is edited.  However,
> when the bottom border is edited (e.g. add a space) then it updates the
> server as well, though now globally all pages' dates are brute force
> overwritten.

Set the properties on the time stamp to "Date this page was last
automatically updated".
This will set the date/time to when any shared border or the content on the
page is changed, whichever is the later.

> Is it possible that all of these issues are FP extension related?  Does it
> make any difference that the site was produced originally in FP2K but is
> now
> under FP03?

Makes no difference

[ Post a follow-up to this message ]

Thank you for all those points, I add some questions/comments below, though
there is a "big picture" issue - am I just seeing some quirks due to
"upgrading" to FP03, or is it possible that all of these issues are FP
extensions (and so server side) related?

"Ronx" wrote:

> Inline below
>
> --
> Ron Symonds   (Microsoft MVP - FrontPage)
> Reply only to group - emails will be deleted unread.
>
>
> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com... 
>
> If the email is not formatted as "formatted text" it is possible that some
> fields will not be included in the email.  Formatted Text usually sends th
e
> entire form.
>
The forms email results are in "HTML" format (and have been for some years).
This all used to work at an earlier data (and a different server).  Also,
there is definitely a "size" issues, since adding or removing items appears
to have an effect.  Moreover, there is added strangness of the "tags" etc as
described above.  A bit confusing, really.
 
>
> The local copy of the .cnt files are not normally published.  If they were
> the counters on the server would be reset with every publish.  Open the we
b
> on the server and update the counter properties there.

OK but at least in FP2K I could (within FP) edit component properties,
change the "starging number" (i.e. the "reset counter to" field), and that
would work.  But now in FP03 it does not!  I cant even tell if that is an
FP03 client side problem, or an FP2002 server side problem (e.g.
extensions??), any thoughts?
> 
>
> Set the properties on the time stamp to "Date this page was last
> automatically updated".
> This will set the date/time to when any shared border or the content on th
e
> page is changed, whichever is the later.
> 
>
> Makes no difference

Sorry, I dont follow the "makes no difference".  Is that to mean that it
wont work regardless of the FP version.  Since at one time this sort of thin
g
did work, and the update Dates were correctly managed by FP on both the
client and server (where as now its only the client).

Also, as a basic rule, pretty much everytime we edit the site "live" it can
lead to very very catastrophic problems, not to mention that such an approac
h
makes "version control" a bit of a 'mare.  So we just dont do it as a matter
of policy (short of an act of God).
>
>
>

[ Post a follow-up to this message ]

inline

--
Ron Symonds   (Microsoft MVP - FrontPage)
Reply only to group - emails will be deleted unread.


"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com...
> Thank you for all those points, I add some questions/comments below,
> though
> there is a "big picture" issue - am I just seeing some quirks due to
> "upgrading" to FP03, or is it possible that all of these issues are FP
> extensions (and so server side) related?

The quirks are more related to the extensions than to FP03.  As far as I
remember, these quirks have been present ever since FP2002 extensions.  I do
not remember them with FP2000 extensions.  I do not use FrontPage forms or
counters on my sites, so I cannot answer from personal experience, just what
I have picked up in these newsgroups.

>
> "Ronx" wrote:
> 
> The forms email results are in "HTML" format (and have been for some
> years).
> This all used to work at an earlier data (and a different server).  Also,
> there is definitely a "size" issues, since adding or removing items
> appears
> to have an effect.  Moreover, there is added strangness of the "tags" etc
> as
> described above.  A bit confusing, really.

Did the previous server use FP2000 extensions?
With the FP2002 extensions, HTML formatting does introduce a size issue.
Its related both to the quantity of data being processed and the number of
fields.
The HTML tags may be another facet of the problem, but I have never seen
this before.
 
>
> OK but at least in FP2K I could (within FP) edit component properties,
> change the "starging number" (i.e. the "reset counter to" field), and that
> would work.  But now in FP03 it does not!  I cant even tell if that is an
> FP03 client side problem, or an FP2002 server side problem (e.g.
> extensions??), any thoughts?

In the local web, are the .cnt marked as "Do not publish"  (a red circle on
the file icon).  This is the normal state for these files to prevent
publishing and over-writing the files on the server.  You can remove this
restriction, publish, and change them back.  I never recommend this method
since too many users forget that last step and wonder why their counters
keep resetting every time they publish.

I just tried this on my test system, and it made no difference to the server
side counter.  Explanation:  The Home page (where I put the counter) name on
the server was changed to Default.htm (from index.htm) when I published the
web, but the .cnt file was published as index.htm.cnt, with no name change.
Another reason for the unwary to edit on the server.
 
>
> Sorry, I dont follow the "makes no difference".  Is that to mean that it
> wont work regardless of the FP version.  Since at one time this sort of
> thing
> did work, and the update Dates were correctly managed by FP on both the
> client and server (where as now its only the client).

If the timestamp properties are set as described, the update dates are
managed at both ends as you want them to be.  It could be that the default
setting in FP2000 was the "...automatic ..." setting  (its been three years
since I used FP2000).

Except as mentioned above, the version of FrontPage client makes no
difference.  However, it is possible that the version of FrontPage
extensions does.

> Also, as a basic rule, pretty much everytime we edit the site "live" it
> can
> lead to very very catastrophic problems, not to mention that such an
> approach
> makes "version control" a bit of a 'mare.  So we just dont do it as a
> matter
> of policy (short of an act of God).

I will not argue with that policy, I use it myself, though not so rigidly.
But some things must be done on the server, such as changing permissions in
folders, and some things are more easily done on the server than locally,
such as resetting counters (which would rarely be the same on the local web,
anyway).

[ Post a follow-up to this message ]

OK, thanks for the extended effort, though it sounds like we are in a bit of
mess then, since it seems that there is nothing that we can do about it (at
least in FP03/2002Server mode).

I suppose it’s the usual giant size madness of "upgrading" for so-called
benefits, but having to learn from scratch all manner of new bugs and
idiosyncrasies.  Frankly, we did not wish to upgrade to 03 (and in general
our experience is that upgrading is absurdly expensive from a cost of
ownership perspective), but somebody provided us with compelling arguments
for it in this case  … silly us … we believed it.

I must say that all of us here very much prefer FP2K for the most part, and
may seek to reverse the upgrade process.  Its just too expensive having to
deal with nonsense like incompatible syntax, or otherwise working facilities
failing in the new environment (and not knowing why, but requiring huge
costs).  Though I can see that it’s a great "make work project" for IT
consultants, unfortunately its ruinously expensive for small businesses.

Why cant new versions offer the “true” backward compatibility, and why c
ant
new versions offer “classic skins”.  We understand it takes some
(experienced) people 3 weeks to transition from FP2K to FP03 just because MS
has moved things around, renamed them, hidden them, etc.  Imagine if you (or
B Gates) came to work and you (or BG) were not paid for three weeks, how
would that feel?

A real shame that nobody cares about the true cost and what deleterious
effect it has on the livelihood of many.

Would you be so kind to pass these comments on to somebody in your firm
(perhaps someone who may have some power to do some good with it)?

"Ronx" wrote:

> inline
>
> --
> Ron Symonds   (Microsoft MVP - FrontPage)
> Reply only to group - emails will be deleted unread.
>
>
> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com... 
>
> The quirks are more related to the extensions than to FP03.  As far as I
> remember, these quirks have been present ever since FP2002 extensions.  I 
do
> not remember them with FP2000 extensions.  I do not use FrontPage forms or
> counters on my sites, so I cannot answer from personal experience, just wh
at
> I have picked up in these newsgroups.
> 
>
> Did the previous server use FP2000 extensions?
> With the FP2002 extensions, HTML formatting does introduce a size issue.
> Its related both to the quantity of data being processed and the number of
> fields.
> The HTML tags may be another facet of the problem, but I have never seen
> this before.
> 
>
> In the local web, are the .cnt marked as "Do not publish"  (a red circle o
n
> the file icon).  This is the normal state for these files to prevent
> publishing and over-writing the files on the server.  You can remove this
> restriction, publish, and change them back.  I never recommend this method
> since too many users forget that last step and wonder why their counters
> keep resetting every time they publish.
>
> I just tried this on my test system, and it made no difference to the serv
er
> side counter.  Explanation:  The Home page (where I put the counter) name 
on
> the server was changed to Default.htm (from index.htm) when I published th
e
> web, but the .cnt file was published as index.htm.cnt, with no name change
.
> Another reason for the unwary to edit on the server.
> 
>
> If the timestamp properties are set as described, the update dates are
> managed at both ends as you want them to be.  It could be that the default
> setting in FP2000 was the "...automatic ..." setting  (its been three year
s
> since I used FP2000).
>
> Except as mentioned above, the version of FrontPage client makes no
> difference.  However, it is possible that the version of FrontPage
> extensions does.
> 
>
> I will not argue with that policy, I use it myself, though not so rigidly.
> But some things must be done on the server, such as changing permissions i
n
> folders, and some things are more easily done on the server than locally,
> such as resetting counters (which would rarely be the same on the local we
b,
> anyway).
>
>
>

[ Post a follow-up to this message ]

>Would you be so kind to pass these comments on to somebody in your firm
>(perhaps someone who may have some power to do some good with it)?

Not possible  - I retired 4 years ago, and have never worked for
Microsoft, anyway.

The Microsoft Wish Program can be reached from here:
http://support.microsoft.com/default.aspx?kbid=114491

--
Ron Symonds   (Microsoft MVP - FrontPage)
Reply only to group - emails will be deleted unread.


"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
news:CC346075-1394-4563-9263-0BBBB26CF42A@microsoft.com...[vbcol=seagreen]
>
> OK, thanks for the extended effort, though it sounds like we are in a bit
> of
> mess then, since it seems that there is nothing that we can do about it
> (at
> least in FP03/2002Server mode).
>
> I suppose it’s the usual giant size madness of "upgrading" for so-called
> benefits, but having to learn from scratch all manner of new bugs and
> idiosyncrasies.  Frankly, we did not wish to upgrade to 03 (and in general
> our experience is that upgrading is absurdly expensive from a cost of
> ownership perspective), but somebody provided us with compelling arguments
> for it in this case  … silly us … we believed it.
>
> I must say that all of us here very much prefer FP2K for the most part,
> and
> may seek to reverse the upgrade process.  Its just too expensive having to
> deal with nonsense like incompatible syntax, or otherwise working
> facilities
> failing in the new environment (and not knowing why, but requiring huge
> costs).  Though I can see that it’s a great "make work project" for IT
> consultants, unfortunately its ruinously expensive for small businesses.
>
> Why cant new versions offer the “true” backward compatibility, and why
> cant
> new versions offer “classic skins”.  We understand it takes some
> (experienced) people 3 weeks to transition from FP2K to FP03 just because
> MS
> has moved things around, renamed them, hidden them, etc.  Imagine if you
> (or
> B Gates) came to work and you (or BG) were not paid for three weeks, how
> would that feel?
>
> A real shame that nobody cares about the true cost and what deleterious
> effect it has on the livelihood of many.
>
> Would you be so kind to pass these comments on to somebody in your firm
> (perhaps someone who may have some power to do some good with it)?
>
> "Ronx" wrote:
> 

[ Post a follow-up to this message ]

There is  FP SE issue w/ long forms - See
[url]http://support.microsoft.com/default.aspx?scid=kb;en-us;820915&Product=fp10se[/url
]

--

 ________________________________________
_____
SBR @ ENJOY (-:              [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!"  (-;
To find the best Newsgroup for FrontPage support see:
http://www.net-sites.com/sitebuilder/newsgroups.asp
 ________________________________________
_____


"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message news:CC
346075-1394-4563-9263-0BBBB26CF42A@microsoft.com...
|
| OK, thanks for the extended effort, though it sounds like we are in a bit 
of
| mess then, since it seems that there is nothing that we can do about it (a
t
| least in FP03/2002Server mode).
|
| I suppose it’s the usual giant size madness of "upgrading" for so-called
| benefits, but having to learn from scratch all manner of new bugs and
| idiosyncrasies.  Frankly, we did not wish to upgrade to 03 (and in general
| our experience is that upgrading is absurdly expensive from a cost of
| ownership perspective), but somebody provided us with compelling arguments
| for it in this case  … silly us … we believed it.
|
| I must say that all of us here very much prefer FP2K for the most part, an
d
| may seek to reverse the upgrade process.  Its just too expensive having to
| deal with nonsense like incompatible syntax, or otherwise working faciliti
es
| failing in the new environment (and not knowing why, but requiring huge
| costs).  Though I can see that it’s a great "make work project" for IT
| consultants, unfortunately its ruinously expensive for small businesses.
|
| Why cant new versions offer the “true” backward compatibility, and why
 cant
| new versions offer “classic skins”.  We understand it takes some
| (experienced) people 3 weeks to transition from FP2K to FP03 just because 
MS
| has moved things around, renamed them, hidden them, etc.  Imagine if you (
or
| B Gates) came to work and you (or BG) were not paid for three weeks, how
| would that feel?
|
| A real shame that nobody cares about the true cost and what deleterious
| effect it has on the livelihood of many.
|
| Would you be so kind to pass these comments on to somebody in your firm
| (perhaps someone who may have some power to do some good with it)?
|
| "Ronx" wrote:
|
| > inline
| >
| > --
| > Ron Symonds   (Microsoft MVP - FrontPage)
| > Reply only to group - emails will be deleted unread.
| >
| >
| > "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
| > news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com...
| > > Thank you for all those points, I add some questions/comments below,
| > > though
| > > there is a "big picture" issue - am I just seeing some quirks due to
| > > "upgrading" to FP03, or is it possible that all of these issues are FP
| > > extensions (and so server side) related?
| >
| > The quirks are more related to the extensions than to FP03.  As far as I
| > remember, these quirks have been present ever since FP2002 extensions.  
I do
| > not remember them with FP2000 extensions.  I do not use FrontPage forms 
or
| > counters on my sites, so I cannot answer from personal experience, just 
what
| > I have picked up in these newsgroups.
| >
| > >
| > > "Ronx" wrote:
| > >
| > >> Inline below
| > >>
| > >> --
| > >> Ron Symonds   (Microsoft MVP - FrontPage)
| > >> Reply only to group - emails will be deleted unread.
| > >>
| > >>
| > >> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
| > >> news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com...
| > >> > Have published a web to a 2002 server, initially with FP2K, and now
| > >> > also
| > >> > with
| > >> > FP03.  There are several components that do not appear to work
| > >> > correctly,
| > >> > eg:
| > >> >
| > >> > 1) Have many forms, all of which had worked at one time.  All but o
ne
| > >> > work
| > >> > on the new installation (including forms in subwebs etc). However o
ne
| > >> > form
| > >> > on
| > >> > returns a "partial" email response on "submit".  That is, it
| > >> > essentially
| > >> > only
| > >> > sends (approx) half of the fieldnames and fieldvalues that have bee
n
| > >> > selected
| > >> > in the save fields dialog.  Sometimes, the fieldvalues have what ap
pear
| > >> > to
| > >> > be
| > >> > html tag snippets.  There are approx 60 fields/values saved (most a
re
| > >> > checkboxes), and only about 30 are returned.  Deleting field from t
he
| > >> > form
| > >> > improves the result, and essentially all fields are obtained when a
bout
| > >> > 30
| > >> > are deleted.  Though there is still some weirdness in that sometime
s
| > >> > there
| > >> > is
| > >> > "blank" inserted into the fieldnames.
| > >> >
| > >> > How is it possible to get the full form returned (as it was possibl
e
| > >> > before)?
| > >>
| > >> If the email is not formatted as "formatted text" it is possible that
| > >> some
| > >> fields will not be included in the email.  Formatted Text usually sen
ds
| > >> the
| > >> entire form.
| > >>
| > > The forms email results are in "HTML" format (and have been for some
| > > years).
| > > This all used to work at an earlier data (and a different server).  Al
so,
| > > there is definitely a "size" issues, since adding or removing items
| > > appears
| > > to have an effect.  Moreover, there is added strangness of the "tags" 
etc
| > > as
| > > described above.  A bit confusing, really.
| >
| > Did the previous server use FP2000 extensions?
| > With the FP2002 extensions, HTML formatting does introduce a size issue.
| > Its related both to the quantity of data being processed and the number 
of
| > fields.
| > The HTML tags may be another facet of the problem, but I have never seen
| > this before.
| >
| > >> >
| > >> > 2) The FP counters will not accept an "overwrite".  E.g. in compone
nt
| > >> > properties there is a field wherein to update the current counter
| > >> > values,
| > >> > and
| > >> > altering this has no effect on the server side.  Nor does the serve
r
| > >> > care
| > >> > if
| > >> > there is direct editing of the cnt file on the client side.  Eventu
ally
| > >> > forced overwrite with ftp upload of cnt files, but ???
| > >>
| > >> The local copy of the .cnt files are not normally published.  If they
| > >> were
| > >> the counters on the server would be reset with every publish.  Open t
he
| > >> web
| > >> on the server and update the counter properties there.
| > >
| > > OK but at least in FP2K I could (within FP) edit component properties,
| > > change the "starging number" (i.e. the "reset counter to" field), and 
that
| > > would work.  But now in FP03 it does not!  I cant even tell if that is
 an
| > > FP03 client side problem, or an FP2002 server side problem (e.g.
| > > extensions??), any thoughts?
| >
| > In the local web, are the .cnt marked as "Do not publish"  (a red circle
 on
| > the file icon).  This is the normal state for these files to prevent
| > publishing and over-writing the files on the server.  You can remove thi
s
| > restriction, publish, and change them back.  I never recommend this meth
od
| > since too many users forget that last step and wonder why their counters
| > keep resetting every time they publish.
| >
| > I just tried this on my test system, and it made no difference to the se
rver
| > side counter.  Explanation:  The Home page (where I put the counter) nam
e on
| > the server was changed to Default.htm (from index.htm) when I published 
the
| > web, but the .cnt file was published as index.htm.cnt, with no name chan
ge.
| > Another reason for the unwary to edit on the server.
| >
| > >>
| > >> >
| > >> > 3) The update Date in the bottom border does not update (on the ser
ver
| > >> > side,
| > >> > but does on the client side) when the body of a page is edited.
| > >> > However,
| > >> > when the bottom border is edited (e.g. add a space) then it updates
 the
| > >> > server as well, though now globally all pages' dates are brute forc
e
| > >> > overwritten.
| > >>
| > >> Set the properties on the time stamp to "Date this page was last
| > >> automatically updated".
| > >> This will set the date/time to when any shared border or the content 
on
| > >> the
| > >> page is changed, whichever is the later.
| > >>
| > >> > Is it possible that all of these issues are FP extension related?  
Does
| > >> > it
| > >> > make any difference that the site was produced originally in FP2K b
ut
| > >> > is
| > >> > now
| > >> > under FP03?
| > >>
| > >> Makes no difference
| > >
| > > Sorry, I dont follow the "makes no difference".  Is that to mean that 
it
| > > wont work regardless of the FP version.  Since at one time this sort o
f
| > > thing
| > > did work, and the update Dates were correctly managed by FP on both th
e
| > > client and server (where as now its only the client).
| >
| > If the timestamp properties are set as described, the update dates are
| > managed at both ends as you want them to be.  It could be that the defau
lt
| > setting in FP2000 was the "...automatic ..." setting  (its been three ye
ars
| > since I used FP2000).
| >
| > Except as mentioned above, the version of FrontPage client makes no
| > difference.  However, it is possible that the version of FrontPage
| > extensions does.
| >
| > > Also, as a basic rule, pretty much everytime we edit the site "live" i
t
| > > can
| > > lead to very very catastrophic problems, not to mention that such an
| > > approach
| > > makes "version control" a bit of a 'mare.  So we just dont do it as a
| > > matter
| > > of policy (short of an act of God).
| >
| > I will not argue with that policy, I use it myself, though not so rigidl
y.
| > But some things must be done on the server, such as changing permissions
 in
| > folders, and some things are more easily done on the server than locally
,
| > such as resetting counters (which would rarely be the same on the local 
web,
| > anyway).
| >
| >
| >

[ Post a follow-up to this message ]

My apologies, though in the thread it has "Ron Symonds   (Microsoft MVP -
FrontPage)"  and so I hope you will forgive any confusion by the (strong)
implication of that title.

"Ronx" wrote:
 
>
> Not possible  - I retired 4 years ago, and have never worked for
> Microsoft, anyway.
>
> The Microsoft Wish Program can be reached from here:
> http://support.microsoft.com/default.aspx?kbid=114491
>
> --
> Ron Symonds   (Microsoft MVP - FrontPage)
> Reply only to group - emails will be deleted unread.
>
>
> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> news:CC346075-1394-4563-9263-0BBBB26CF42A@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]

See http://mvp.support.microsoft.com/de...le=f
lat

--

 ________________________________________
_____
SBR @ ENJOY (-:              [ Microsoft MVP - FrontPage ]
"Warning - Using the F1 Key will not break anything!"  (-;
To find the best Newsgroup for FrontPage support see:
http://www.net-sites.com/sitebuilder/newsgroups.asp
 ________________________________________
_____


"DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message news:CC
0ED518-EC0B-46C1-ABAB-76B65444D739@microsoft.com...
| My apologies, though in the thread it has "Ron Symonds   (Microsoft MVP -
| FrontPage)"  and so I hope you will forgive any confusion by the (strong)
| implication of that title.
|
| "Ronx" wrote:
|
| > >Would you be so kind to pass these comments on to somebody in your firm
| > >(perhaps someone who may have some power to do some good with it)?
| >
| > Not possible  - I retired 4 years ago, and have never worked for
| > Microsoft, anyway.
| >
| > The Microsoft Wish Program can be reached from here:
| > http://support.microsoft.com/default.aspx?kbid=114491
| >
| > --
| > Ron Symonds   (Microsoft MVP - FrontPage)
| > Reply only to group - emails will be deleted unread.
| >
| >
| > "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
| > news:CC346075-1394-4563-9263-0BBBB26CF42A@microsoft.com...
| > >
| > > OK, thanks for the extended effort, though it sounds like we are in a 
bit
| > > of
| > > mess then, since it seems that there is nothing that we can do about i
t
| > > (at
| > > least in FP03/2002Server mode).
| > >
| > > I suppose it’s the usual giant size madness of "upgrading" for 
so-called
| > > benefits, but having to learn from scratch all manner of new bugs and
| > > idiosyncrasies.  Frankly, we did not wish to upgrade to 03 (and in gen
eral
| > > our experience is that upgrading is absurdly expensive from a cost of
| > > ownership perspective), but somebody provided us with compelling argum
ents
| > > for it in this case  … silly us … we believed it.
| > >
| > > I must say that all of us here very much prefer FP2K for the most part
,
| > > and
| > > may seek to reverse the upgrade process.  Its just too expensive havin
g to
| > > deal with nonsense like incompatible syntax, or otherwise working
| > > facilities
| > > failing in the new environment (and not knowing why, but requiring hug
e
| > > costs).  Though I can see that it’s a great "make work project"
 for IT
| > > consultants, unfortunately its ruinously expensive for small businesse
s.
| > >
| > > Why cant new versions offer the “true” backward compatibil
ity, and why
| > > cant
| > > new versions offer “classic skins”.  We understand it take
s some
| > > (experienced) people 3 weeks to transition from FP2K to FP03 just beca
use
| > > MS
| > > has moved things around, renamed them, hidden them, etc.  Imagine if y
ou
| > > (or
| > > B Gates) came to work and you (or BG) were not paid for three weeks, h
ow
| > > would that feel?
| > >
| > > A real shame that nobody cares about the true cost and what deleteriou
s
| > > effect it has on the livelihood of many.
| > >
| > > Would you be so kind to pass these comments on to somebody in your fir
m
| > > (perhaps someone who may have some power to do some good with it)?
| > >
| > > "Ronx" wrote:
| > >
| > >> inline
| > >>
| > >> --
| > >> Ron Symonds   (Microsoft MVP - FrontPage)
| > >> Reply only to group - emails will be deleted unread.
| > >>
| > >>
| > >> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
| > >> news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com...
| > >> > Thank you for all those points, I add some questions/comments below
,
| > >> > though
| > >> > there is a "big picture" issue - am I just seeing some quirks due t
o
| > >> > "upgrading" to FP03, or is it possible that all of these issues are
 FP
| > >> > extensions (and so server side) related?
| > >>
| > >> The quirks are more related to the extensions than to FP03.  As far a
s I
| > >> remember, these quirks have been present ever since FP2002 extensions
.  I
| > >> do
| > >> not remember them with FP2000 extensions.  I do not use FrontPage for
ms
| > >> or
| > >> counters on my sites, so I cannot answer from personal experience, ju
st
| > >> what
| > >> I have picked up in these newsgroups.
| > >>
| > >> >
| > >> > "Ronx" wrote:
| > >> >
| > >> >> Inline below
| > >> >>
| > >> >> --
| > >> >> Ron Symonds   (Microsoft MVP - FrontPage)
| > >> >> Reply only to group - emails will be deleted unread.
| > >> >>
| > >> >>
| > >> >> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in messa
ge
| > >> >> news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com...
| > >> >> > Have published a web to a 2002 server, initially with FP2K, and 
now
| > >> >> > also
| > >> >> > with
| > >> >> > FP03.  There are several components that do not appear to work
| > >> >> > correctly,
| > >> >> > eg:
| > >> >> >
| > >> >> > 1) Have many forms, all of which had worked at one time.  All bu
t
| > >> >> > one
| > >> >> > work
| > >> >> > on the new installation (including forms in subwebs etc). Howeve
r
| > >> >> > one
| > >> >> > form
| > >> >> > on
| > >> >> > returns a "partial" email response on "submit".  That is, it
| > >> >> > essentially
| > >> >> > only
| > >> >> > sends (approx) half of the fieldnames and fieldvalues that have 
been
| > >> >> > selected
| > >> >> > in the save fields dialog.  Sometimes, the fieldvalues have what
| > >> >> > appear
| > >> >> > to
| > >> >> > be
| > >> >> > html tag snippets.  There are approx 60 fields/values saved (mos
t
| > >> >> > are
| > >> >> > checkboxes), and only about 30 are returned.  Deleting field fro
m
| > >> >> > the
| > >> >> > form
| > >> >> > improves the result, and essentially all fields are obtained whe
n
| > >> >> > about
| > >> >> > 30
| > >> >> > are deleted.  Though there is still some weirdness in that somet
imes
| > >> >> > there
| > >> >> > is
| > >> >> > "blank" inserted into the fieldnames.
| > >> >> >
| > >> >> > How is it possible to get the full form returned (as it was poss
ible
| > >> >> > before)?
| > >> >>
| > >> >> If the email is not formatted as "formatted text" it is possible t
hat
| > >> >> some
| > >> >> fields will not be included in the email.  Formatted Text usually
| > >> >> sends
| > >> >> the
| > >> >> entire form.
| > >> >>
| > >> > The forms email results are in "HTML" format (and have been for som
e
| > >> > years).
| > >> > This all used to work at an earlier data (and a different server).
| > >> > Also,
| > >> > there is definitely a "size" issues, since adding or removing items
| > >> > appears
| > >> > to have an effect.  Moreover, there is added strangness of the "tag
s"
| > >> > etc
| > >> > as
| > >> > described above.  A bit confusing, really.
| > >>
| > >> Did the previous server use FP2000 extensions?
| > >> With the FP2002 extensions, HTML formatting does introduce a size iss
ue.
| > >> Its related both to the quantity of data being processed and the numb
er
| > >> of
| > >> fields.
| > >> The HTML tags may be another facet of the problem, but I have never s
een
| > >> this before.
| > >>
| > >> >> >
| > >> >> > 2) The FP counters will not accept an "overwrite".  E.g. in
| > >> >> > component
| > >> >> > properties there is a field wherein to update the current counte
r
| > >> >> > values,
| > >> >> > and
| > >> >> > altering this has no effect on the server side.  Nor does the se
rver
| > >> >> > care
| > >> >> > if
| > >> >> > there is direct editing of the cnt file on the client side.
| > >> >> > Eventually
| > >> >> > forced overwrite with ftp upload of cnt files, but ???
| > >> >>
| > >> >> The local copy of the .cnt files are not normally published.  If t
hey
| > >> >> were
| > >> >> the counters on the server would be reset with every publish.  Ope
n
| > >> >> the
| > >> >> web
| > >> >> on the server and update the counter properties there.
| > >> >
| > >> > OK but at least in FP2K I could (within FP) edit component properti
es,
| > >> > change the "starging number" (i.e. the "reset counter to" field), a
nd
| > >> > that
| > >> > would work.  But now in FP03 it does not!  I cant even tell if that
 is
| > >> > an
| > >> > FP03 client side problem, or an FP2002 server side problem (e.g.
| > >> > extensions??), any thoughts?
| > >>
| > >> In the local web, are the .cnt marked as "Do not publish"  (a red cir
cle
| > >> on
| > >> the file icon).  This is the normal state for these files to prevent
| > >> publishing and over-writing the files on the server.  You can remove 
this
| > >> restriction, publish, and change them back.  I never recommend this
| > >> method
| > >> since too many users forget that last step and wonder why their count
ers
| > >> keep resetting every time they publish.
| > >>
| > >> I just tried this on my test system, and it made no difference to the
| > >> server
| > >> side counter.  Explanation:  The Home page (where I put the counter) 
name
| > >> on
| > >> the server was changed to Default.htm (from index.htm) when I publish
ed
| > >> the
| > >> web, but the .cnt file was published as index.htm.cnt, with no name
| > >> change.
| > >> Another reason for the unwary to edit on the server.
| > >>
| > >> >>
| > >> >> >
| > >> >> > 3) The update Date in the bottom border does not update (on the
| > >> >> > server
| > >> >> > side,
| > >> >> > but does on the client side) when the body of a page is edited.
| > >> >> > However,
| > >> >> > when the bottom border is edited (e.g. add a space) then it upda
tes
| > >> >> > the
| > >> >> > server as well, though now globally all pages' dates are brute f
orce
| > >> >> > overwritten.
| > >> >>
| > >> >> Set the properties on the time stamp to "Date this page was last
| > >> >> automatically updated".
| > >> >> This will set the date/time to when any shared border or the conte
nt
| > >> >> on
| > >> >> the
| > >> >> page is changed, whichever is the later.
| > >> >>
| > >> >> > Is it possible that all of these issues are FP extension related
?
| > >> >> > Does
| > >> >> > it
| > >> >> > make any difference that the site was produced originally in FP2
K
| > >> >> > but
| > >> >> > is
| > >> >> > now
| > >> >> > under FP03?
| > >> >>
| > >> >> Makes no difference
| > >> >
| > >> > Sorry, I dont follow the "makes no difference".  Is that to mean th
at
| > >> > it
| > >> > wont work regardless of the FP version.  Since at one time this sor
t of
| > >> > thing
| > >> > did work, and the update Dates were correctly managed by FP on both
 the
| > >> > client and server (where as now its only the client).
| > >>
| > >> If the timestamp properties are set as described, the update dates ar
e
| > >> managed at both ends as you want them to be.  It could be that the
| > >> default
| > >> setting in FP2000 was the "...automatic ..." setting  (its been three
| > >> years
| > >> since I used FP2000).
| > >>
| > >> Except as mentioned above, the version of FrontPage client makes no
| > >> difference.  However, it is possible that the version of FrontPage
| > >> extensions does.
| > >>
| > >> > Also, as a basic rule, pretty much everytime we edit the site "live
" it
| > >> > can
| > >> > lead to very very catastrophic problems, not to mention that such a
n
| > >> > approach
| > >> > makes "version control" a bit of a 'mare.  So we just dont do it as
 a
| > >> > matter
| > >> > of policy (short of an act of God).
| > >>
| > >> I will not argue with that policy, I use it myself, though not so
| > >> rigidly.
| > >> But some things must be done on the server, such as changing permissi
ons
| > >> in
| > >> folders, and some things are more easily done on the server than loca
lly,
| > >> such as resetting counters (which would rarely be the same on the loc
al
| > >> web,
| > >> anyway).
| > >>
| > >>
| > >>
| >
| >
| >

[ Post a follow-up to this message ]

Thanks for that, spoke with ISP, they say that all of their facilities are
already compliant with the points in that support link ... not really sure
what to do now ... we have informed that re-writing the page from scratch in
FP03 should resolve it, but this did not work either, and in any case
rewriting hundreds of (complex) pages from scratch (just to upgrade from 2k
to 03 seems) is ruinously expensive.

"Stefan B Rusynko" wrote:

> There is  FP SE issue w/ long forms - See
> [url]http://support.microsoft.com/default.aspx?scid=kb;en-us;820915&Product=fp10se[/u
rl]
>
> --
>
>  ________________________________________
_____
> SBR @ ENJOY (-:              [ Microsoft MVP - FrontPage ]
> "Warning - Using the F1 Key will not break anything!"  (-;
> To find the best Newsgroup for FrontPage support see:
>   http://www.net-sites.com/sitebuilder/newsgroups.asp
>  ________________________________________
_____
>
>
> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message news:
CC346075-1394-4563-9263-0BBBB26CF42A@microsoft.com...
> |
> | OK, thanks for the extended effort, though it sounds like we are in a bi
t of
> | mess then, since it seems that there is nothing that we can do about it 
(at
> | least in FP03/2002Server mode).
> |
> | I suppose it’s the usual giant size madness of "upgrading" for so
-called
> | benefits, but having to learn from scratch all manner of new bugs and
> | idiosyncrasies.  Frankly, we did not wish to upgrade to 03 (and in gener
al
> | our experience is that upgrading is absurdly expensive from a cost of
> | ownership perspective), but somebody provided us with compelling argumen
ts
> | for it in this case  … silly us … we believed it.
> |
> | I must say that all of us here very much prefer FP2K for the most part, 
and
> | may seek to reverse the upgrade process.  Its just too expensive having 
to
> | deal with nonsense like incompatible syntax, or otherwise working facili
ties
> | failing in the new environment (and not knowing why, but requiring huge
> | costs).  Though I can see that it’s a great "make work project" f
or IT
> | consultants, unfortunately its ruinously expensive for small businesses.
> |
> | Why cant new versions offer the “true” backward compatibilit
y, and why cant
> | new versions offer “classic skins”.  We understand it takes 
some
> | (experienced) people 3 weeks to transition from FP2K to FP03 just becaus
e MS
> | has moved things around, renamed them, hidden them, etc.  Imagine if you
 (or
> | B Gates) came to work and you (or BG) were not paid for three weeks, how
> | would that feel?
> |
> | A real shame that nobody cares about the true cost and what deleterious
> | effect it has on the livelihood of many.
> |
> | Would you be so kind to pass these comments on to somebody in your firm
> | (perhaps someone who may have some power to do some good with it)?
> |
> | "Ronx" wrote:
> |
> | > inline
> | >
> | > --
> | > Ron Symonds   (Microsoft MVP - FrontPage)
> | > Reply only to group - emails will be deleted unread.
> | >
> | >
> | > "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in message
> | > news:467B52FA-0773-4FB5-B255-2868975B6BF9@microsoft.com...
> | > > Thank you for all those points, I add some questions/comments below,
> | > > though
> | > > there is a "big picture" issue - am I just seeing some quirks due to
> | > > "upgrading" to FP03, or is it possible that all of these issues are 
FP
> | > > extensions (and so server side) related?
> | >
> | > The quirks are more related to the extensions than to FP03.  As far as
 I
> | > remember, these quirks have been present ever since FP2002 extensions.
  I do
> | > not remember them with FP2000 extensions.  I do not use FrontPage form
s or
> | > counters on my sites, so I cannot answer from personal experience, jus
t what
> | > I have picked up in these newsgroups.
> | >
> | > >
> | > > "Ronx" wrote:
> | > >
> | > >> Inline below
> | > >>
> | > >> --
> | > >> Ron Symonds   (Microsoft MVP - FrontPage)
> | > >> Reply only to group - emails will be deleted unread.
> | > >>
> | > >>
> | > >> "DeltaGamma" <DeltaGamma@discussions.microsoft.com> wrote in messag
e
> | > >> news:7F0F5ABF-6FE5-4542-A4DC-EE9D36DA69E7@microsoft.com...
> | > >> > Have published a web to a 2002 server, initially with FP2K, and n
ow
> | > >> > also
> | > >> > with
> | > >> > FP03.  There are several components that do not appear to work
> | > >> > correctly,
> | > >> > eg:
> | > >> >
> | > >> > 1) Have many forms, all of which had worked at one time.  All but
 one
> | > >> > work
> | > >> > on the new installation (including forms in subwebs etc). However
 one
> | > >> > form
> | > >> > on
> | > >> > returns a "partial" email response on "submit".  That is, it
> | > >> > essentially
> | > >> > only
> | > >> > sends (approx) half of the fieldnames and fieldvalues that have b
een
> | > >> > selected
> | > >> > in the save fields dialog.  Sometimes, the fieldvalues have what 
appear
> | > >> > to
> | > >> > be
> | > >> > html tag snippets.  There are approx 60 fields/values saved (most
 are
> | > >> > checkboxes), and only about 30 are returned.  Deleting field from
 the
> | > >> > form
> | > >> > improves the result, and essentially all fields are obtained when
 about
> | > >> > 30
> | > >> > are deleted.  Though there is still some weirdness in that someti
mes
> | > >> > there
> | > >> > is
> | > >> > "blank" inserted into the fieldnames.
> | > >> >
> | > >> > How is it possible to get the full form returned (as it was possi
ble
> | > >> > before)?
> | > >>
> | > >> If the email is not formatted as "formatted text" it is possible th
at
> | > >> some
> | > >> fields will not be included in the email.  Formatted Text usually s
ends
> | > >> the
> | > >> entire form.
> | > >>
> | > > The forms email results are in "HTML" format (and have been for some
> | > > years).
> | > > This all used to work at an earlier data (and a different server).  
Also,
> | > > there is definitely a "size" issues, since adding or removing items
> | > > appears
> | > > to have an effect.  Moreover, there is added strangness of the "tags
" etc
> | > > as
> | > > described above.  A bit confusing, really.
> | >
> | > Did the previous server use FP2000 extensions?
> | > With the FP2002 extensions, HTML formatting does introduce a size issu
e.
> | > Its related both to the quantity of data being processed and the numbe
r of
> | > fields.
> | > The HTML tags may be another facet of the problem, but I have never se
en
> | > this before.
> | >
> | > >> >
> | > >> > 2) The FP counters will not accept an "overwrite".  E.g. in compo
nent
> | > >> > properties there is a field wherein to update the current counter
> | > >> > values,
> | > >> > and
> | > >> > altering this has no effect on the server side.  Nor does the ser
ver
> | > >> > care
> | > >> > if
> | > >> > there is direct editing of the cnt file on the client side.  Even
tually
> | > >> > forced overwrite with ftp upload of cnt files, but ???
> | > >>
> | > >> The local copy of the .cnt files are not normally published.  If th
ey
> | > >> were
> | > >> the counters on the server would be reset with every publish.  Open
 the
> | > >> web
> | > >> on the server and update the counter properties there.
> | > >
> | > > OK but at least in FP2K I could (within FP) edit component propertie
s,
> | > > change the "starging number" (i.e. the "reset counter to" field), an
d that
> | > > would work.  But now in FP03 it does not!  I cant even tell if that 
is an
> | > > FP03 client side problem, or an FP2002 server side problem (e.g.
> | > > extensions??), any thoughts?
> | >
> | > In the local web, are the .cnt marked as "Do not publish"  (a red circ
le on
> | > the file icon).  This is the normal state for these files to prevent
> | > publishing and over-writing the files on the server.  You can remove t
his
> | > restriction, publish, and change them back.  I never recommend this me
thod
> | > since too many users forget that last step and wonder why their counte
rs
> | > keep resetting every time they publish.
> | >
> | > I just tried this on my test system, and it made no difference to the 
server
> | > side counter.  Explanation:  The Home page (where I put the counter) n
ame on
> | > the server was changed to Default.htm (from index.htm) when I publishe
d the
> | > web, but the .cnt file was published as index.htm.cnt, with no name ch
ange.
> | > Another reason for the unwary to edit on the server.
> | >
> | > >>
> | > >> >
> | > >> > 3) The update Date in the bottom border does not update (on the s
erver
> | > >> > side,
> | > >> > but does on the client side) when the body of a page is edited.
> | > >> > However,
> | > >> > when the bottom border is edited (e.g. add a space) then it updat
es the
> | > >> > server as well, though now globally all pages' dates are brute fo
rce
> | > >> > overwritten.
> | > >>
> | > >> Set the properties on the time stamp to "Date this page was last
> | > >> automatically updated".
> | > >> This will set the date/time to when any shared border or the conten
t on
> | > >> the
> | > >> page is changed, whichever is the later.
> | > >>
> | > >> > Is it possible that all of these issues are FP extension related?
  Does
> | > >> > it
> | > >> > make any difference that the site was produced originally in FP2K
 but
> | > >> > is
> | > >> > now
> | > >> > under FP03?
> | > >>
> | > >> Makes no difference
> | > >
> | > > Sorry, I dont follow the "makes no difference".  Is that to mean tha
t it
> | > > wont work regardless of the FP version.  Since at one time this sort
 of
> | > > thing
> | > > did work, and the update Dates were correctly managed by FP on both 
the
> | > > client and server (where as now its only the client).
> | >
> | > If the timestamp properties are set as described, the update dates are
> | > managed at both ends as you want them to be.  It could be that the def
ault
> | > setting in FP2000 was the "...automatic ..." setting  (its been three 
years
> | > since I used FP2000).
> | >
> | > Except as mentioned above, the version of FrontPage client makes no
> | > difference.  However, it is possible that the version of FrontPage
> | > extensions does.
> | >
> | > > Also, as a basic rule, pretty much everytime we edit the site "live"
 it
> | > > can
> | > > lead to very very catastrophic problems, not to mention that such an
> | > > approach
> | > > makes "version control" a bit of a 'mare.  So we just dont do it as 
a
> | > > matter
> | > > of policy (short of an act of God).
> | >
> | > I will not argue with that policy, I use it myself, though not so rigi
dly.
> | > But some things must be done on the server, such as changing permissio
ns in
> | > folders, and some things are more easily done on the server than local
ly,
> | > such as resetting counters (which would rarely be the same on the loca
l web,
> | > anyway).
> | >
> | >
> | >
>
>
>

[ Post a follow-up to this message ]