Hello,
I am using Visual Web Developer and decared a Public Variable in the Class
section. I assigned a value in the load section, and on a button I set it
up to increment, but it always delivers the same value, 1. When I increment
the variable from the button, shouldn't it hold the new value? I also
tried declaring the variable as a Friend, but it wasn't any more friendly.
;)
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
Handles Me.Load
i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
i = i + 1
MsgBox(i, MsgBoxStyle.Information)
End Sub
End Class
10  1424 
HTTP is stateless. This means on every request to the server, a new Page
object is created. Since it is always a new object, whatever values you set
on the old object, will not persist.
However, even if everything worked as you imagine with there being one
instance of a Page object all the time, your code would still not run as
expected. This is because you are always setting i to 0 in Page_Load. So
after the user clicks the button, i would be set to 0, then incremented by 1
in the click handler. Then on the next click the same thing would happen,
and i would always be at 1.
However, even if you fix your code to only set it to 0 in Page_Load when
it's not a postback (or just not do anything, since 0 is the default for an
integer anyway), your code would not work as you expect for the reasons
given in the beginning of the post.
I recommend you get a book on ASP.NET and do some reading about how it all
works before proceeding much further. Without an understand of the page
lifecycle and the basic mechanics of ASP.NET it will be hard to get far.
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl... Hello,
I am using Visual Web Developer and decared a Public Variable in the Class
section. I assigned a value in the load section, and on a button I set it
up to increment, but it always delivers the same value, 1. When I
increment the variable from the button, shouldn't it hold the new value?
I also tried declaring the variable as a Friend, but it wasn't any more
friendly. ;)
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
i = i + 1
MsgBox(i, MsgBoxStyle.Information)
End Sub
End Class
But you must remember that in the client/server model of the web, each time
you request this web page, a BRAND NEW instance of this class is created and
your variable is created again, from scratch. You aren't continuing with
the same page class instance the second time you use the page.
You must store your variable in a more persistant location, such as a
cookie, the cache, viewstate or a database to be able to reuse it across
page calls.
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl... Hello,
I am using Visual Web Developer and decared a Public Variable in the Class
section. I assigned a value in the load section, and on a button I set it
up to increment, but it always delivers the same value, 1. When I
increment the variable from the button, shouldn't it hold the new value?
I also tried declaring the variable as a Friend, but it wasn't any more
friendly. ;)
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
i = i + 1
MsgBox(i, MsgBoxStyle.Information)
End Sub
End Class
Thank you Marina. You are right about not understanding what is happening.
Here is why I am not following. I placed a textbox on the same form using
the same button, and was able to increment the value in the textbox. The
code is below:
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
Handles Me.Load
'i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
'i = i + 1
'MsgBox(i, MsgBoxStyle.Information)
TextBox1.Text = TextBox1.Text + 1
End Sub
End Class
If the page refreshes each time I click the button, then why doesn't the
textbox lose its value? Maybe I'm not making sense, but its how I see it.
;)
God Bless,
Mark
"Marina Levit [MVP]" <so*****@nospam.com> wrote in message
news:eL**************@TK2MSFTNGP12.phx.gbl... HTTP is stateless. This means on every request to the server, a new Page
object is created. Since it is always a new object, whatever values you
set on the old object, will not persist.
However, even if everything worked as you imagine with there being one
instance of a Page object all the time, your code would still not run as
expected. This is because you are always setting i to 0 in Page_Load. So
after the user clicks the button, i would be set to 0, then incremented by
1 in the click handler. Then on the next click the same thing would
happen, and i would always be at 1.
However, even if you fix your code to only set it to 0 in Page_Load when
it's not a postback (or just not do anything, since 0 is the default for
an integer anyway), your code would not work as you expect for the reasons
given in the beginning of the post.
I recommend you get a book on ASP.NET and do some reading about how it all
works before proceeding much further. Without an understand of the page
lifecycle and the basic mechanics of ASP.NET it will be hard to get far.
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl... Hello,
I am using Visual Web Developer and decared a Public Variable in the
Class section. I assigned a value in the load section, and on a button I
set it up to increment, but it always delivers the same value, 1. When I
increment the variable from the button, shouldn't it hold the new value?
I also tried declaring the variable as a Friend, but it wasn't any more
friendly. ;)
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
i = i + 1
MsgBox(i, MsgBoxStyle.Information)
End Sub
End Class
That's because Textboxes (as well as many of the Web Forms Controls)
maintain their own state like this:
When data is posted to the server, that data becomes the DEFAULT value of
the control as it is sent back down to the browser. Now, when the browser
sends that data back up to the server, the server uses this data as the
starting point from which to work. No data is actually being stored
(persisted) on the server.
A good analogy of how client/server works:
When you look up at the stars at night, you are seeing what they looked like
in the past. For all you know, the star you are looking at doesn't even
exist anymore.
When you look at a web page (nice segway, huh?), you are seeing the RESULTS
of some server processing, but by the time you see those results, the server
has disconnected from you and moved on to handle someone else's request.
None of your data is stored on the server. If you re-submit the page you
are looking at in your browser, the server must create a brand new instance
of a page class, place band new instances of controls on this page and
attempt to restore certain controls back to their previous values. Of
course, the server doesn't have any of these previous values, so it is up to
the client to post those values up to the server. That's what's happening
with your textbox example.
The ONLY way to persist data on the server is to store that data somewhere
that the server can get a hold of it. As I mentioned in my last reply:
ViewState, the Cache, a database, cookies, a flat file, etc. are all good
candidates.
As Marina suggested, a good understanding of client/server communication as
well as a good understanding of the Page class's life-cycle would be a good
place to start.
Good luck,
Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... Thank you Marina. You are right about not understanding what is
happening. Here is why I am not following. I placed a textbox on the same
form using the same button, and was able to increment the value in the
textbox. The code is below:
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
'i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
'i = i + 1
'MsgBox(i, MsgBoxStyle.Information)
TextBox1.Text = TextBox1.Text + 1
End Sub
End Class
If the page refreshes each time I click the button, then why doesn't the
textbox lose its value? Maybe I'm not making sense, but its how I see it.
;)
God Bless,
Mark
"Marina Levit [MVP]" <so*****@nospam.com> wrote in message
news:eL**************@TK2MSFTNGP12.phx.gbl... HTTP is stateless. This means on every request to the server, a new Page
object is created. Since it is always a new object, whatever values you
set on the old object, will not persist.
However, even if everything worked as you imagine with there being one
instance of a Page object all the time, your code would still not run as
expected. This is because you are always setting i to 0 in Page_Load. So
after the user clicks the button, i would be set to 0, then incremented
by 1 in the click handler. Then on the next click the same thing would
happen, and i would always be at 1.
However, even if you fix your code to only set it to 0 in Page_Load when
it's not a postback (or just not do anything, since 0 is the default for
an integer anyway), your code would not work as you expect for the
reasons given in the beginning of the post.
I recommend you get a book on ASP.NET and do some reading about how it
all works before proceeding much further. Without an understand of the
page lifecycle and the basic mechanics of ASP.NET it will be hard to get
far.
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl... Hello,
I am using Visual Web Developer and decared a Public Variable in the
Class section. I assigned a value in the load section, and on a button
I set it up to increment, but it always delivers the same value, 1.
When I increment the variable from the button, shouldn't it hold the
new value? I also tried declaring the variable as a Friend, but it
wasn't any more friendly. ;)
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
i = i + 1
MsgBox(i, MsgBoxStyle.Information)
End Sub
End Class
Hello Scott,
I understand what you are saying, but I don't understand why this is any
different than using Access VBA or another language in a client server
setting. If the data doesn't persist on the server, it is becuase noone
addressed that issue? I have an analogy about visual studio... It is like
putting a Peterbilt body, a Cummins engine, and an Eaton Transmission onto a
horse drawn wagon. Why not rebuild the chassis while you're (meaning
Microsoft) at it. ;)
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:e5**************@tk2msftngp13.phx.gbl... That's because Textboxes (as well as many of the Web Forms Controls)
maintain their own state like this:
When data is posted to the server, that data becomes the DEFAULT value of
the control as it is sent back down to the browser. Now, when the browser
sends that data back up to the server, the server uses this data as the
starting point from which to work. No data is actually being stored
(persisted) on the server.
A good analogy of how client/server works:
When you look up at the stars at night, you are seeing what they looked
like in the past. For all you know, the star you are looking at doesn't
even exist anymore.
When you look at a web page (nice segway, huh?), you are seeing the
RESULTS of some server processing, but by the time you see those results,
the server has disconnected from you and moved on to handle someone else's
request. None of your data is stored on the server. If you re-submit the
page you are looking at in your browser, the server must create a brand
new instance of a page class, place band new instances of controls on this
page and attempt to restore certain controls back to their previous
values. Of course, the server doesn't have any of these previous values,
so it is up to the client to post those values up to the server. That's
what's happening with your textbox example.
The ONLY way to persist data on the server is to store that data somewhere
that the server can get a hold of it. As I mentioned in my last reply:
ViewState, the Cache, a database, cookies, a flat file, etc. are all good
candidates.
As Marina suggested, a good understanding of client/server communication
as well as a good understanding of the Page class's life-cycle would be a
good place to start.
Good luck,
Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... Thank you Marina. You are right about not understanding what is
happening. Here is why I am not following. I placed a textbox on the
same form using the same button, and was able to increment the value in
the textbox. The code is below:
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
'i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
'i = i + 1
'MsgBox(i, MsgBoxStyle.Information)
TextBox1.Text = TextBox1.Text + 1
End Sub
End Class
If the page refreshes each time I click the button, then why doesn't the
textbox lose its value? Maybe I'm not making sense, but its how I see
it. ;)
God Bless,
Mark
"Marina Levit [MVP]" <so*****@nospam.com> wrote in message
news:eL**************@TK2MSFTNGP12.phx.gbl... HTTP is stateless. This means on every request to the server, a new Page
object is created. Since it is always a new object, whatever values you
set on the old object, will not persist.
However, even if everything worked as you imagine with there being one
instance of a Page object all the time, your code would still not run as
expected. This is because you are always setting i to 0 in Page_Load. So
after the user clicks the button, i would be set to 0, then incremented
by 1 in the click handler. Then on the next click the same thing would
happen, and i would always be at 1.
However, even if you fix your code to only set it to 0 in Page_Load when
it's not a postback (or just not do anything, since 0 is the default for
an integer anyway), your code would not work as you expect for the
reasons given in the beginning of the post.
I recommend you get a book on ASP.NET and do some reading about how it
all works before proceeding much further. Without an understand of the
page lifecycle and the basic mechanics of ASP.NET it will be hard to get
far.
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl...
Hello,
I am using Visual Web Developer and decared a Public Variable in the
Class section. I assigned a value in the load section, and on a button
I set it up to increment, but it always delivers the same value, 1.
When I increment the variable from the button, shouldn't it hold the
new value? I also tried declaring the variable as a Friend, but it
wasn't any more friendly. ;)
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
i = i + 1
MsgBox(i, MsgBoxStyle.Information)
End Sub
End Class
To address your questions/comments.
HTTP client/server is not at all how programming Access with VBA works.
Access VBA programs are client only, not client/server (unless you put the
Access DB on a shared server, in which case it is client/server, but not
HTTP client/server - so the comparison is still not valid).
As for data not persisting on the server, it is not Visual Studio or
Microsoft's fault, this is the very nature of HTTP and the WWW. This is by
design and is not a glitch or a bug. It is to facilitate the hundreds of
millions of clients out there connecting to the (somewhat smaller by
comparison) millions of servers out there. A server just can't keep a
dedicated connection open to each client that wants it. If it did, then
we'd all be getting "busy signals" quite often when we try to visit any web
site.
In short, HTTP client/server is just a different architecture than client
only because of the distributed nature of the Internet. Putting an Access
VBA application on a server doesn't make that architecture client/server in
the same sense because each client DOES have a continuous connection to the
server (and tying up precious resources as well). Imagine if 1,000 (just to
use a very small number for demonstration purposes) people tried to get at
your VBA application at the same time. How about 1,000,000? Wouldn't it
make sense to only be connected to the user for just the time it takes to
process their request, and free up the database for someone else to use?
If you are going to do any web development at all (Microsoft .NET, Java
Server Pages, PHP, etc.) you must understand this concept well and also
understand that it is not something brought on by a vendor, it is the way
web development works regardless of platform or product.
Good luck,
-Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:OU**************@TK2MSFTNGP10.phx.gbl... Hello Scott,
I understand what you are saying, but I don't understand why this is any
different than using Access VBA or another language in a client server
setting. If the data doesn't persist on the server, it is becuase noone
addressed that issue? I have an analogy about visual studio... It is like
putting a Peterbilt body, a Cummins engine, and an Eaton Transmission onto
a horse drawn wagon. Why not rebuild the chassis while you're (meaning
Microsoft) at it. ;)
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:e5**************@tk2msftngp13.phx.gbl... That's because Textboxes (as well as many of the Web Forms Controls)
maintain their own state like this:
When data is posted to the server, that data becomes the DEFAULT value of
the control as it is sent back down to the browser. Now, when the browser
sends that data back up to the server, the server uses this data as the
starting point from which to work. No data is actually being stored
(persisted) on the server.
A good analogy of how client/server works:
When you look up at the stars at night, you are seeing what they looked
like in the past. For all you know, the star you are looking at doesn't
even exist anymore.
When you look at a web page (nice segway, huh?), you are seeing the
RESULTS of some server processing, but by the time you see those results,
the server has disconnected from you and moved on to handle someone
else's request. None of your data is stored on the server. If you
re-submit the page you are looking at in your browser, the server must
create a brand new instance of a page class, place band new instances of
controls on this page and attempt to restore certain controls back to
their previous values. Of course, the server doesn't have any of these
previous values, so it is up to the client to post those values up to the
server. That's what's happening with your textbox example.
The ONLY way to persist data on the server is to store that data
somewhere that the server can get a hold of it. As I mentioned in my
last reply: ViewState, the Cache, a database, cookies, a flat file, etc.
are all good candidates.
As Marina suggested, a good understanding of client/server communication
as well as a good understanding of the Page class's life-cycle would be a
good place to start.
Good luck,
Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... Thank you Marina. You are right about not understanding what is
happening. Here is why I am not following. I placed a textbox on the
same form using the same button, and was able to increment the value in
the textbox. The code is below:
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
'i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
'i = i + 1
'MsgBox(i, MsgBoxStyle.Information)
TextBox1.Text = TextBox1.Text + 1
End Sub
End Class
If the page refreshes each time I click the button, then why doesn't the
textbox lose its value? Maybe I'm not making sense, but its how I see
it. ;)
God Bless,
Mark
"Marina Levit [MVP]" <so*****@nospam.com> wrote in message
news:eL**************@TK2MSFTNGP12.phx.gbl...
HTTP is stateless. This means on every request to the server, a new
Page object is created. Since it is always a new object, whatever
values you set on the old object, will not persist.
However, even if everything worked as you imagine with there being one
instance of a Page object all the time, your code would still not run
as expected. This is because you are always setting i to 0 in
Page_Load. So after the user clicks the button, i would be set to 0,
then incremented by 1 in the click handler. Then on the next click the
same thing would happen, and i would always be at 1.
However, even if you fix your code to only set it to 0 in Page_Load
when it's not a postback (or just not do anything, since 0 is the
default for an integer anyway), your code would not work as you expect
for the reasons given in the beginning of the post.
I recommend you get a book on ASP.NET and do some reading about how it
all works before proceeding much further. Without an understand of the
page lifecycle and the basic mechanics of ASP.NET it will be hard to
get far.
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:uj**************@TK2MSFTNGP09.phx.gbl...
> Hello,
>
> I am using Visual Web Developer and decared a Public Variable in the
> Class section. I assigned a value in the load section, and on a
> button I set it up to increment, but it always delivers the same
> value, 1. When I increment the variable from the button, shouldn't it
> hold the new value? I also tried declaring the variable as a Friend,
> but it wasn't any more friendly. ;)
>
> Partial Class test
>
> Inherits System.Web.UI.Page
>
> Public i As Integer
>
> Protected Sub Page_Load(ByVal sender As Object, ByVal e As
> System.EventArgs) Handles Me.Load
>
> i = 0
>
> End Sub
>
> Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
> System.EventArgs) Handles Button2.Click
>
> i = i + 1
>
> MsgBox(i, MsgBoxStyle.Information)
>
> End Sub
>
> End Class
>
>
Scott,
I'm not trying to give you hard time by disagreeing with you, but I do. ;)
I understand what you are saying about the nature of http and www, but I
believe that the internet can be exactly like a client server on a computer
network. If that is what Bill Gates wanted that is what would happen. Bill
runs the show. If he wanted to change the protocols of the internet and how
his browser worked, he could do it. For the most part, millions of people
don't concurrently access the bulk of websites. Maybe hundreds would be a
high number, so servers could in most cases handle the traffic. I think its
a matter of design. I have linked SQL Server tables to Access apps, on my
local machine, to a server in Atlanta, so I know the technology is there.
Its just a matter of "doing it right", which unfortunately is a Microsoft
weakpoint. It always falls short of the mark in all of its apps.
But that is just my opinion and I know it will anger a lot of Microsoft
devotees and I'm sorry for that. ;)
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:ei**************@TK2MSFTNGP09.phx.gbl... To address your questions/comments.
HTTP client/server is not at all how programming Access with VBA works.
Access VBA programs are client only, not client/server (unless you put the
Access DB on a shared server, in which case it is client/server, but not
HTTP client/server - so the comparison is still not valid).
As for data not persisting on the server, it is not Visual Studio or
Microsoft's fault, this is the very nature of HTTP and the WWW. This is
by design and is not a glitch or a bug. It is to facilitate the hundreds
of millions of clients out there connecting to the (somewhat smaller by
comparison) millions of servers out there. A server just can't keep a
dedicated connection open to each client that wants it. If it did, then
we'd all be getting "busy signals" quite often when we try to visit any
web site.
In short, HTTP client/server is just a different architecture than client
only because of the distributed nature of the Internet. Putting an Access
VBA application on a server doesn't make that architecture client/server
in the same sense because each client DOES have a continuous connection to
the server (and tying up precious resources as well). Imagine if 1,000
(just to use a very small number for demonstration purposes) people tried
to get at your VBA application at the same time. How about 1,000,000?
Wouldn't it make sense to only be connected to the user for just the time
it takes to process their request, and free up the database for someone
else to use?
If you are going to do any web development at all (Microsoft .NET, Java
Server Pages, PHP, etc.) you must understand this concept well and also
understand that it is not something brought on by a vendor, it is the way
web development works regardless of platform or product.
Good luck,
-Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:OU**************@TK2MSFTNGP10.phx.gbl... Hello Scott,
I understand what you are saying, but I don't understand why this is any
different than using Access VBA or another language in a client server
setting. If the data doesn't persist on the server, it is becuase noone
addressed that issue? I have an analogy about visual studio... It is
like putting a Peterbilt body, a Cummins engine, and an Eaton
Transmission onto a horse drawn wagon. Why not rebuild the chassis while
you're (meaning Microsoft) at it. ;)
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:e5**************@tk2msftngp13.phx.gbl... That's because Textboxes (as well as many of the Web Forms Controls)
maintain their own state like this:
When data is posted to the server, that data becomes the DEFAULT value
of the control as it is sent back down to the browser. Now, when the
browser sends that data back up to the server, the server uses this data
as the starting point from which to work. No data is actually being
stored (persisted) on the server.
A good analogy of how client/server works:
When you look up at the stars at night, you are seeing what they looked
like in the past. For all you know, the star you are looking at doesn't
even exist anymore.
When you look at a web page (nice segway, huh?), you are seeing the
RESULTS of some server processing, but by the time you see those
results, the server has disconnected from you and moved on to handle
someone else's request. None of your data is stored on the server. If
you re-submit the page you are looking at in your browser, the server
must create a brand new instance of a page class, place band new
instances of controls on this page and attempt to restore certain
controls back to their previous values. Of course, the server doesn't
have any of these previous values, so it is up to the client to post
those values up to the server. That's what's happening with your
textbox example.
The ONLY way to persist data on the server is to store that data
somewhere that the server can get a hold of it. As I mentioned in my
last reply: ViewState, the Cache, a database, cookies, a flat file, etc.
are all good candidates.
As Marina suggested, a good understanding of client/server communication
as well as a good understanding of the Page class's life-cycle would be
a good place to start.
Good luck,
Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Thank you Marina. You are right about not understanding what is
happening. Here is why I am not following. I placed a textbox on the
same form using the same button, and was able to increment the value in
the textbox. The code is below:
Partial Class test
Inherits System.Web.UI.Page
Public i As Integer
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
'i = 0
End Sub
Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Button2.Click
'i = i + 1
'MsgBox(i, MsgBoxStyle.Information)
TextBox1.Text = TextBox1.Text + 1
End Sub
End Class
If the page refreshes each time I click the button, then why doesn't
the textbox lose its value? Maybe I'm not making sense, but its how I
see it. ;)
God Bless,
Mark
"Marina Levit [MVP]" <so*****@nospam.com> wrote in message
news:eL**************@TK2MSFTNGP12.phx.gbl...
> HTTP is stateless. This means on every request to the server, a new
> Page object is created. Since it is always a new object, whatever
> values you set on the old object, will not persist.
>
> However, even if everything worked as you imagine with there being one
> instance of a Page object all the time, your code would still not run
> as expected. This is because you are always setting i to 0 in
> Page_Load. So after the user clicks the button, i would be set to 0,
> then incremented by 1 in the click handler. Then on the next click the
> same thing would happen, and i would always be at 1.
>
> However, even if you fix your code to only set it to 0 in Page_Load
> when it's not a postback (or just not do anything, since 0 is the
> default for an integer anyway), your code would not work as you expect
> for the reasons given in the beginning of the post.
>
> I recommend you get a book on ASP.NET and do some reading about how it
> all works before proceeding much further. Without an understand of the
> page lifecycle and the basic mechanics of ASP.NET it will be hard to
> get far.
>
> "Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
> news:uj**************@TK2MSFTNGP09.phx.gbl...
>> Hello,
>>
>> I am using Visual Web Developer and decared a Public Variable in the
>> Class section. I assigned a value in the load section, and on a
>> button I set it up to increment, but it always delivers the same
>> value, 1. When I increment the variable from the button, shouldn't
>> it hold the new value? I also tried declaring the variable as a
>> Friend, but it wasn't any more friendly. ;)
>>
>> Partial Class test
>>
>> Inherits System.Web.UI.Page
>>
>> Public i As Integer
>>
>> Protected Sub Page_Load(ByVal sender As Object, ByVal e As
>> System.EventArgs) Handles Me.Load
>>
>> i = 0
>>
>> End Sub
>>
>> Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
>> System.EventArgs) Handles Button2.Click
>>
>> i = i + 1
>>
>> MsgBox(i, MsgBoxStyle.Information)
>>
>> End Sub
>>
>> End Class
>>
>>
>
>
Mark,
You are entitled to your opinion, but what we are discussing here isn't
opinion based.
FACT: The Internet and the World Wide Web are not goverened by Microsoft.
If anything, it is goverened by The World Wide Web Consortium. When software
manufacturers wish to use the Internet in a different way, they make
different software. Instant Messaging is a good example of this. When you
use an instant messanger product (from AOL, MS, Yahoo, or anyone else), your
message is travelling over the Internet, but NOT via HTTP. And, because
different software manufacturers come up with their own protocols that are
proprietary, you run into compatibility issues between software. Try IM-ing
a MSN Messanger user via AOL's AIM - not going to happen! On the other hand
you can use different email software clients to send/recieve email because
email (all email) travels using the mailto: protocol - - it's a standard.
FACT: HTTP is the Internet's web server protocol. HTTP was not invented,
nor is it goverened by any software manufacturer. It is a standard protocol
that the WWW is designed to run on. You can't just up and change it or the
WWW would collapse.
Now, to address your specific comments...see inline below:
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:OC****************@TK2MSFTNGP11.phx.gbl... Scott,
I'm not trying to give you hard time by disagreeing with you, but I do. ;)
I understand what you are saying about the nature of http and www, but I
believe that the internet can be exactly like a client server on a
computer network.
On who's network? Would that network run NETBIOS, NETBUI or some other
protocol? And what if one application on one network wanted to communicate
with another application on another network, but the two networks run on
different protocols?
What you are suggesting would only be possible if there were standard
protocols that everyone's software understood and only if the network could
support millions of simultaneous connections. Perhaps one day, but not
today.
If that is what Bill Gates wanted that is what would happen. Bill runs
the show. If he wanted to change the protocols of the internet and how
his browser worked, he could do it.
ROFLMAO: I'm sorry, but a statement like this just tells me that you really
don't have an understanding of how things *actually* work. There are
countless initives that Bill and MS pushed hard over the years, that wound
up in the garbage because the rest of the world didn't agree. Can you say
"MS Bob"?
For the most part, millions of people don't concurrently access the bulk
of websites. Maybe hundreds would be a high number, so servers could in
most cases handle the traffic.
What source do you get this information from? I'd say that is flat out not
true at all. And, even if it were true, many (millions...not hundreds)
sites DO experience millions of hits per day. So, shouldn't the network be
set up in a way that can handle the highest possible volumne, not the
lowest?
I think its a matter of design.
Yes. You are 100% absolutlely correct. The Internet was absolutley designed
like this intentionally and it works quite well. Just because you have to
change your client programming mentality doesn't make HTTP client/server bad
or wrong...just different.
I have linked SQL Server tables to Access apps, on my local machine, to a
server in Atlanta, so I know the technology is there.
And, what was the highest volume your applicaiton ever had to deal with?
With this, I think you've hit the nail on the head. No one is saying that
*all* applications must be HTTP based. In your situation, you found a
solution that worked for you. It's just that on the world's largest
network, that isn't how things are done. The network MUST be able to handle
extremely high volumes of traffic that come from different platforms and
from different software. That design specification can only mandate one
thing: STANDARDS. HTTP is that standard.
Its just a matter of "doing it right", which unfortunately is a Microsoft
weakpoint. It always falls short of the mark in all of its apps.
Again, I fail to understand why you are blaming Microsoft for something that
wasn't designed, built or tested by anyone from MS. In fact, the Internet
and its fundamental protocol, TCP/IP, was created before there even was a
Microsoft (mid 1960's by the Defense Advanced Research Projects Agency or
DARPA). The WWW was created by Tim Berners-Lee, who is now the President of
the World Wide Web Consortium (which is not accountable to any software
vendor).
But that is just my opinion and I know it will anger a lot of Microsoft
devotees and I'm sorry for that. ;)
It's not a matter of angering any MS devotees. It's a matter of you not
understanding how the system is built or who built it as well as how and
why it was built that way. That's not my opinion. Based on your
statements, it is clear that you need to go back and try to understand the
very nature of the Internet before you apply non-truths to it.
Good luck,
-Scott
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:ei**************@TK2MSFTNGP09.phx.gbl... To address your questions/comments.
HTTP client/server is not at all how programming Access with VBA works.
Access VBA programs are client only, not client/server (unless you put
the Access DB on a shared server, in which case it is client/server, but
not HTTP client/server - so the comparison is still not valid).
As for data not persisting on the server, it is not Visual Studio or
Microsoft's fault, this is the very nature of HTTP and the WWW. This is
by design and is not a glitch or a bug. It is to facilitate the hundreds
of millions of clients out there connecting to the (somewhat smaller by
comparison) millions of servers out there. A server just can't keep a
dedicated connection open to each client that wants it. If it did, then
we'd all be getting "busy signals" quite often when we try to visit any
web site.
In short, HTTP client/server is just a different architecture than client
only because of the distributed nature of the Internet. Putting an
Access VBA application on a server doesn't make that architecture
client/server in the same sense because each client DOES have a
continuous connection to the server (and tying up precious resources as
well). Imagine if 1,000 (just to use a very small number for
demonstration purposes) people tried to get at your VBA application at
the same time. How about 1,000,000? Wouldn't it make sense to only be
connected to the user for just the time it takes to process their
request, and free up the database for someone else to use?
If you are going to do any web development at all (Microsoft .NET, Java
Server Pages, PHP, etc.) you must understand this concept well and also
understand that it is not something brought on by a vendor, it is the way
web development works regardless of platform or product.
Good luck,
-Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:OU**************@TK2MSFTNGP10.phx.gbl... Hello Scott,
I understand what you are saying, but I don't understand why this is any
different than using Access VBA or another language in a client server
setting. If the data doesn't persist on the server, it is becuase noone
addressed that issue? I have an analogy about visual studio... It is
like putting a Peterbilt body, a Cummins engine, and an Eaton
Transmission onto a horse drawn wagon. Why not rebuild the chassis
while you're (meaning Microsoft) at it. ;)
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:e5**************@tk2msftngp13.phx.gbl...
That's because Textboxes (as well as many of the Web Forms Controls)
maintain their own state like this:
When data is posted to the server, that data becomes the DEFAULT value
of the control as it is sent back down to the browser. Now, when the
browser sends that data back up to the server, the server uses this
data as the starting point from which to work. No data is actually
being stored (persisted) on the server.
A good analogy of how client/server works:
When you look up at the stars at night, you are seeing what they looked
like in the past. For all you know, the star you are looking at
doesn't even exist anymore.
When you look at a web page (nice segway, huh?), you are seeing the
RESULTS of some server processing, but by the time you see those
results, the server has disconnected from you and moved on to handle
someone else's request. None of your data is stored on the server. If
you re-submit the page you are looking at in your browser, the server
must create a brand new instance of a page class, place band new
instances of controls on this page and attempt to restore certain
controls back to their previous values. Of course, the server doesn't
have any of these previous values, so it is up to the client to post
those values up to the server. That's what's happening with your
textbox example.
The ONLY way to persist data on the server is to store that data
somewhere that the server can get a hold of it. As I mentioned in my
last reply: ViewState, the Cache, a database, cookies, a flat file,
etc. are all good candidates.
As Marina suggested, a good understanding of client/server
communication as well as a good understanding of the Page class's
life-cycle would be a good place to start.
Good luck,
Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
> Thank you Marina. You are right about not understanding what is
> happening. Here is why I am not following. I placed a textbox on the
> same form using the same button, and was able to increment the value
> in the textbox. The code is below:
> Partial Class test
> Inherits System.Web.UI.Page
>
> Public i As Integer
>
> Protected Sub Page_Load(ByVal sender As Object, ByVal e As
> System.EventArgs) Handles Me.Load
>
> 'i = 0
>
> End Sub
>
> Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
> System.EventArgs) Handles Button2.Click
>
> 'i = i + 1
>
> 'MsgBox(i, MsgBoxStyle.Information)
>
> TextBox1.Text = TextBox1.Text + 1
>
> End Sub
>
> End Class
>
>
> If the page refreshes each time I click the button, then why doesn't
> the textbox lose its value? Maybe I'm not making sense, but its how I
> see it. ;)
>
> God Bless,
>
> Mark
>
>
>
>
>
> "Marina Levit [MVP]" <so*****@nospam.com> wrote in message
> news:eL**************@TK2MSFTNGP12.phx.gbl...
>> HTTP is stateless. This means on every request to the server, a new
>> Page object is created. Since it is always a new object, whatever
>> values you set on the old object, will not persist.
>>
>> However, even if everything worked as you imagine with there being
>> one instance of a Page object all the time, your code would still not
>> run as expected. This is because you are always setting i to 0 in
>> Page_Load. So after the user clicks the button, i would be set to 0,
>> then incremented by 1 in the click handler. Then on the next click
>> the same thing would happen, and i would always be at 1.
>>
>> However, even if you fix your code to only set it to 0 in Page_Load
>> when it's not a postback (or just not do anything, since 0 is the
>> default for an integer anyway), your code would not work as you
>> expect for the reasons given in the beginning of the post.
>>
>> I recommend you get a book on ASP.NET and do some reading about how
>> it all works before proceeding much further. Without an understand of
>> the page lifecycle and the basic mechanics of ASP.NET it will be hard
>> to get far.
>>
>> "Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
>> news:uj**************@TK2MSFTNGP09.phx.gbl...
>>> Hello,
>>>
>>> I am using Visual Web Developer and decared a Public Variable in the
>>> Class section. I assigned a value in the load section, and on a
>>> button I set it up to increment, but it always delivers the same
>>> value, 1. When I increment the variable from the button, shouldn't
>>> it hold the new value? I also tried declaring the variable as a
>>> Friend, but it wasn't any more friendly. ;)
>>>
>>> Partial Class test
>>>
>>> Inherits System.Web.UI.Page
>>>
>>> Public i As Integer
>>>
>>> Protected Sub Page_Load(ByVal sender As Object, ByVal e As
>>> System.EventArgs) Handles Me.Load
>>>
>>> i = 0
>>>
>>> End Sub
>>>
>>> Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
>>> System.EventArgs) Handles Button2.Click
>>>
>>> i = i + 1
>>>
>>> MsgBox(i, MsgBoxStyle.Information)
>>>
>>> End Sub
>>>
>>> End Class
>>>
>>>
>>
>>
>
>
Hello Scott,
I don't want to drag this on. I understand your point of view and believe
what you say about the current state of the internet. I respect your
knowledge and ability and you are right, I don't understand the workings,
but I do believe they can be improved. Of course I'm a guy that thinks
evolution is silly nonsense. ;)
Thank you for your response.
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:ux****************@tk2msftngp13.phx.gbl... Mark,
You are entitled to your opinion, but what we are discussing here isn't
opinion based.
FACT: The Internet and the World Wide Web are not goverened by Microsoft.
If anything, it is goverened by The World Wide Web Consortium. When
software manufacturers wish to use the Internet in a different way, they
make different software. Instant Messaging is a good example of this.
When you use an instant messanger product (from AOL, MS, Yahoo, or anyone
else), your message is travelling over the Internet, but NOT via HTTP.
And, because different software manufacturers come up with their own
protocols that are proprietary, you run into compatibility issues between
software. Try IM-ing a MSN Messanger user via AOL's AIM - not going to
happen! On the other hand you can use different email software clients to
send/recieve email because email (all email) travels using the mailto:
protocol - - it's a standard.
FACT: HTTP is the Internet's web server protocol. HTTP was not invented,
nor is it goverened by any software manufacturer. It is a standard
protocol that the WWW is designed to run on. You can't just up and change
it or the WWW would collapse.
Now, to address your specific comments...see inline below:
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:OC****************@TK2MSFTNGP11.phx.gbl... Scott,
I'm not trying to give you hard time by disagreeing with you, but I do.
;) I understand what you are saying about the nature of http and www, but
I believe that the internet can be exactly like a client server on a
computer network.
On who's network? Would that network run NETBIOS, NETBUI or some other
protocol? And what if one application on one network wanted to
communicate with another application on another network, but the two
networks run on different protocols?
What you are suggesting would only be possible if there were standard
protocols that everyone's software understood and only if the network
could support millions of simultaneous connections. Perhaps one day, but
not today.
If that is what Bill Gates wanted that is what would happen. Bill runs
the show. If he wanted to change the protocols of the internet and how
his browser worked, he could do it.
ROFLMAO: I'm sorry, but a statement like this just tells me that you
really don't have an understanding of how things *actually* work. There
are countless initives that Bill and MS pushed hard over the years, that
wound up in the garbage because the rest of the world didn't agree. Can
you say "MS Bob"?
For the most part, millions of people don't concurrently access the bulk
of websites. Maybe hundreds would be a high number, so servers could in
most cases handle the traffic.
What source do you get this information from? I'd say that is flat out
not true at all. And, even if it were true, many (millions...not
hundreds) sites DO experience millions of hits per day. So, shouldn't the
network be set up in a way that can handle the highest possible volumne,
not the lowest?
I think its a matter of design.
Yes. You are 100% absolutlely correct. The Internet was absolutley
designed like this intentionally and it works quite well. Just because
you have to change your client programming mentality doesn't make HTTP
client/server bad or wrong...just different.
I have linked SQL Server tables to Access apps, on my local machine, to
a server in Atlanta, so I know the technology is there.
And, what was the highest volume your applicaiton ever had to deal with?
With this, I think you've hit the nail on the head. No one is saying that
*all* applications must be HTTP based. In your situation, you found a
solution that worked for you. It's just that on the world's largest
network, that isn't how things are done. The network MUST be able to
handle extremely high volumes of traffic that come from different
platforms and from different software. That design specification can only
mandate one thing: STANDARDS. HTTP is that standard.
Its just a matter of "doing it right", which unfortunately is a Microsoft
weakpoint. It always falls short of the mark in all of its apps.
Again, I fail to understand why you are blaming Microsoft for something
that wasn't designed, built or tested by anyone from MS. In fact, the
Internet and its fundamental protocol, TCP/IP, was created before there
even was a Microsoft (mid 1960's by the Defense Advanced Research Projects
Agency or DARPA). The WWW was created by Tim Berners-Lee, who is now the
President of the World Wide Web Consortium (which is not accountable to
any software vendor).
But that is just my opinion and I know it will anger a lot of Microsoft
devotees and I'm sorry for that. ;)
It's not a matter of angering any MS devotees. It's a matter of you not
understanding how the system is built or who built it as well as how and
why it was built that way. That's not my opinion. Based on your
statements, it is clear that you need to go back and try to understand the
very nature of the Internet before you apply non-truths to it.
Good luck,
-Scott
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:ei**************@TK2MSFTNGP09.phx.gbl... To address your questions/comments.
HTTP client/server is not at all how programming Access with VBA works.
Access VBA programs are client only, not client/server (unless you put
the Access DB on a shared server, in which case it is client/server, but
not HTTP client/server - so the comparison is still not valid).
As for data not persisting on the server, it is not Visual Studio or
Microsoft's fault, this is the very nature of HTTP and the WWW. This is
by design and is not a glitch or a bug. It is to facilitate the
hundreds of millions of clients out there connecting to the (somewhat
smaller by comparison) millions of servers out there. A server just
can't keep a dedicated connection open to each client that wants it. If
it did, then we'd all be getting "busy signals" quite often when we try
to visit any web site.
In short, HTTP client/server is just a different architecture than
client only because of the distributed nature of the Internet. Putting
an Access VBA application on a server doesn't make that architecture
client/server in the same sense because each client DOES have a
continuous connection to the server (and tying up precious resources as
well). Imagine if 1,000 (just to use a very small number for
demonstration purposes) people tried to get at your VBA application at
the same time. How about 1,000,000? Wouldn't it make sense to only be
connected to the user for just the time it takes to process their
request, and free up the database for someone else to use?
If you are going to do any web development at all (Microsoft .NET, Java
Server Pages, PHP, etc.) you must understand this concept well and also
understand that it is not something brought on by a vendor, it is the
way web development works regardless of platform or product.
Good luck,
-Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:OU**************@TK2MSFTNGP10.phx.gbl...
Hello Scott,
I understand what you are saying, but I don't understand why this is
any different than using Access VBA or another language in a client
server setting. If the data doesn't persist on the server, it is
becuase noone addressed that issue? I have an analogy about visual
studio... It is like putting a Peterbilt body, a Cummins engine, and an
Eaton Transmission onto a horse drawn wagon. Why not rebuild the
chassis while you're (meaning Microsoft) at it. ;)
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:e5**************@tk2msftngp13.phx.gbl...
> That's because Textboxes (as well as many of the Web Forms Controls)
> maintain their own state like this:
>
> When data is posted to the server, that data becomes the DEFAULT value
> of the control as it is sent back down to the browser. Now, when the
> browser sends that data back up to the server, the server uses this
> data as the starting point from which to work. No data is actually
> being stored (persisted) on the server.
>
> A good analogy of how client/server works:
>
> When you look up at the stars at night, you are seeing what they
> looked like in the past. For all you know, the star you are looking
> at doesn't even exist anymore.
>
> When you look at a web page (nice segway, huh?), you are seeing the
> RESULTS of some server processing, but by the time you see those
> results, the server has disconnected from you and moved on to handle
> someone else's request. None of your data is stored on the server. If
> you re-submit the page you are looking at in your browser, the server
> must create a brand new instance of a page class, place band new
> instances of controls on this page and attempt to restore certain
> controls back to their previous values. Of course, the server doesn't
> have any of these previous values, so it is up to the client to post
> those values up to the server. That's what's happening with your
> textbox example.
>
> The ONLY way to persist data on the server is to store that data
> somewhere that the server can get a hold of it. As I mentioned in my
> last reply: ViewState, the Cache, a database, cookies, a flat file,
> etc. are all good candidates.
>
> As Marina suggested, a good understanding of client/server
> communication as well as a good understanding of the Page class's
> life-cycle would be a good place to start.
>
> Good luck,
>
> Scott
>
>
>
> "Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
> news:%2****************@tk2msftngp13.phx.gbl...
>> Thank you Marina. You are right about not understanding what is
>> happening. Here is why I am not following. I placed a textbox on the
>> same form using the same button, and was able to increment the value
>> in the textbox. The code is below:
>> Partial Class test
>> Inherits System.Web.UI.Page
>>
>> Public i As Integer
>>
>> Protected Sub Page_Load(ByVal sender As Object, ByVal e As
>> System.EventArgs) Handles Me.Load
>>
>> 'i = 0
>>
>> End Sub
>>
>> Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
>> System.EventArgs) Handles Button2.Click
>>
>> 'i = i + 1
>>
>> 'MsgBox(i, MsgBoxStyle.Information)
>>
>> TextBox1.Text = TextBox1.Text + 1
>>
>> End Sub
>>
>> End Class
>>
>>
>> If the page refreshes each time I click the button, then why doesn't
>> the textbox lose its value? Maybe I'm not making sense, but its how
>> I see it. ;)
>>
>> God Bless,
>>
>> Mark
>>
>>
>>
>>
>>
>> "Marina Levit [MVP]" <so*****@nospam.com> wrote in message
>> news:eL**************@TK2MSFTNGP12.phx.gbl...
>>> HTTP is stateless. This means on every request to the server, a new
>>> Page object is created. Since it is always a new object, whatever
>>> values you set on the old object, will not persist.
>>>
>>> However, even if everything worked as you imagine with there being
>>> one instance of a Page object all the time, your code would still
>>> not run as expected. This is because you are always setting i to 0
>>> in Page_Load. So after the user clicks the button, i would be set to
>>> 0, then incremented by 1 in the click handler. Then on the next
>>> click the same thing would happen, and i would always be at 1.
>>>
>>> However, even if you fix your code to only set it to 0 in Page_Load
>>> when it's not a postback (or just not do anything, since 0 is the
>>> default for an integer anyway), your code would not work as you
>>> expect for the reasons given in the beginning of the post.
>>>
>>> I recommend you get a book on ASP.NET and do some reading about how
>>> it all works before proceeding much further. Without an understand
>>> of the page lifecycle and the basic mechanics of ASP.NET it will be
>>> hard to get far.
>>>
>>> "Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
>>> news:uj**************@TK2MSFTNGP09.phx.gbl...
>>>> Hello,
>>>>
>>>> I am using Visual Web Developer and decared a Public Variable in
>>>> the Class section. I assigned a value in the load section, and on
>>>> a button I set it up to increment, but it always delivers the same
>>>> value, 1. When I increment the variable from the button, shouldn't
>>>> it hold the new value? I also tried declaring the variable as a
>>>> Friend, but it wasn't any more friendly. ;)
>>>>
>>>> Partial Class test
>>>>
>>>> Inherits System.Web.UI.Page
>>>>
>>>> Public i As Integer
>>>>
>>>> Protected Sub Page_Load(ByVal sender As Object, ByVal e As
>>>> System.EventArgs) Handles Me.Load
>>>>
>>>> i = 0
>>>>
>>>> End Sub
>>>>
>>>> Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
>>>> System.EventArgs) Handles Button2.Click
>>>>
>>>> i = i + 1
>>>>
>>>> MsgBox(i, MsgBoxStyle.Information)
>>>>
>>>> End Sub
>>>>
>>>> End Class
>>>>
>>>>
>>>
>>>
>>
>>
>
>
I would just say that before you can improve something, shouldn't you
understand what it is and what it does in the first place, though?
I hear what you are saying and, please understand that I mean no disrespect.
But, if you understood how and why the Internet works as it does, you might
come to the realization that it works just fine the way it is and that the
*stateless* nature of the web isn't a drawback or something to be solved.
Just keep an open mind as you investigate.
Good luck!
-Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:uZ****************@TK2MSFTNGP12.phx.gbl... Hello Scott,
I don't want to drag this on. I understand your point of view and believe
what you say about the current state of the internet. I respect your
knowledge and ability and you are right, I don't understand the workings,
but I do believe they can be improved. Of course I'm a guy that thinks
evolution is silly nonsense. ;)
Thank you for your response.
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:ux****************@tk2msftngp13.phx.gbl... Mark,
You are entitled to your opinion, but what we are discussing here isn't
opinion based.
FACT: The Internet and the World Wide Web are not goverened by
Microsoft. If anything, it is goverened by The World Wide Web Consortium.
When software manufacturers wish to use the Internet in a different way,
they make different software. Instant Messaging is a good example of
this. When you use an instant messanger product (from AOL, MS, Yahoo, or
anyone else), your message is travelling over the Internet, but NOT via
HTTP. And, because different software manufacturers come up with their
own protocols that are proprietary, you run into compatibility issues
between software. Try IM-ing a MSN Messanger user via AOL's AIM - not
going to happen! On the other hand you can use different email software
clients to send/recieve email because email (all email) travels using the
mailto: protocol - - it's a standard.
FACT: HTTP is the Internet's web server protocol. HTTP was not invented,
nor is it goverened by any software manufacturer. It is a standard
protocol that the WWW is designed to run on. You can't just up and
change it or the WWW would collapse.
Now, to address your specific comments...see inline below:
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:OC****************@TK2MSFTNGP11.phx.gbl... Scott,
I'm not trying to give you hard time by disagreeing with you, but I do.
;) I understand what you are saying about the nature of http and www,
but I believe that the internet can be exactly like a client server on a
computer network.
On who's network? Would that network run NETBIOS, NETBUI or some other
protocol? And what if one application on one network wanted to
communicate with another application on another network, but the two
networks run on different protocols?
What you are suggesting would only be possible if there were standard
protocols that everyone's software understood and only if the network
could support millions of simultaneous connections. Perhaps one day, but
not today.
If that is what Bill Gates wanted that is what would happen. Bill runs
the show. If he wanted to change the protocols of the internet and how
his browser worked, he could do it.
ROFLMAO: I'm sorry, but a statement like this just tells me that you
really don't have an understanding of how things *actually* work. There
are countless initives that Bill and MS pushed hard over the years, that
wound up in the garbage because the rest of the world didn't agree. Can
you say "MS Bob"?
For the most part, millions of people don't concurrently access the bulk
of websites. Maybe hundreds would be a high number, so servers could in
most cases handle the traffic.
What source do you get this information from? I'd say that is flat out
not true at all. And, even if it were true, many (millions...not
hundreds) sites DO experience millions of hits per day. So, shouldn't
the network be set up in a way that can handle the highest possible
volumne, not the lowest?
I think its a matter of design.
Yes. You are 100% absolutlely correct. The Internet was absolutley
designed like this intentionally and it works quite well. Just because
you have to change your client programming mentality doesn't make HTTP
client/server bad or wrong...just different.
I have linked SQL Server tables to Access apps, on my local machine, to
a server in Atlanta, so I know the technology is there.
And, what was the highest volume your applicaiton ever had to deal with?
With this, I think you've hit the nail on the head. No one is saying
that *all* applications must be HTTP based. In your situation, you found
a solution that worked for you. It's just that on the world's largest
network, that isn't how things are done. The network MUST be able to
handle extremely high volumes of traffic that come from different
platforms and from different software. That design specification can
only mandate one thing: STANDARDS. HTTP is that standard.
Its just a matter of "doing it right", which unfortunately is a
Microsoft weakpoint. It always falls short of the mark in all of its
apps.
Again, I fail to understand why you are blaming Microsoft for something
that wasn't designed, built or tested by anyone from MS. In fact, the
Internet and its fundamental protocol, TCP/IP, was created before there
even was a Microsoft (mid 1960's by the Defense Advanced Research
Projects Agency or DARPA). The WWW was created by Tim Berners-Lee, who
is now the President of the World Wide Web Consortium (which is not
accountable to any software vendor).
But that is just my opinion and I know it will anger a lot of Microsoft
devotees and I'm sorry for that. ;)
It's not a matter of angering any MS devotees. It's a matter of you not
understanding how the system is built or who built it as well as how and
why it was built that way. That's not my opinion. Based on your
statements, it is clear that you need to go back and try to understand
the very nature of the Internet before you apply non-truths to it.
Good luck,
-Scott
God Bless,
Mark
"Scott M." <s-***@nospam.nospam> wrote in message
news:ei**************@TK2MSFTNGP09.phx.gbl...
To address your questions/comments.
HTTP client/server is not at all how programming Access with VBA works.
Access VBA programs are client only, not client/server (unless you put
the Access DB on a shared server, in which case it is client/server,
but not HTTP client/server - so the comparison is still not valid).
As for data not persisting on the server, it is not Visual Studio or
Microsoft's fault, this is the very nature of HTTP and the WWW. This
is by design and is not a glitch or a bug. It is to facilitate the
hundreds of millions of clients out there connecting to the (somewhat
smaller by comparison) millions of servers out there. A server just
can't keep a dedicated connection open to each client that wants it.
If it did, then we'd all be getting "busy signals" quite often when we
try to visit any web site.
In short, HTTP client/server is just a different architecture than
client only because of the distributed nature of the Internet. Putting
an Access VBA application on a server doesn't make that architecture
client/server in the same sense because each client DOES have a
continuous connection to the server (and tying up precious resources as
well). Imagine if 1,000 (just to use a very small number for
demonstration purposes) people tried to get at your VBA application at
the same time. How about 1,000,000? Wouldn't it make sense to only be
connected to the user for just the time it takes to process their
request, and free up the database for someone else to use?
If you are going to do any web development at all (Microsoft .NET, Java
Server Pages, PHP, etc.) you must understand this concept well and also
understand that it is not something brought on by a vendor, it is the
way web development works regardless of platform or product.
Good luck,
-Scott
"Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
news:OU**************@TK2MSFTNGP10.phx.gbl...
> Hello Scott,
>
> I understand what you are saying, but I don't understand why this is
> any different than using Access VBA or another language in a client
> server setting. If the data doesn't persist on the server, it is
> becuase noone addressed that issue? I have an analogy about visual
> studio... It is like putting a Peterbilt body, a Cummins engine, and
> an Eaton Transmission onto a horse drawn wagon. Why not rebuild the
> chassis while you're (meaning Microsoft) at it. ;)
>
> God Bless,
>
> Mark
>
>
>
> "Scott M." <s-***@nospam.nospam> wrote in message
> news:e5**************@tk2msftngp13.phx.gbl...
>> That's because Textboxes (as well as many of the Web Forms Controls)
>> maintain their own state like this:
>>
>> When data is posted to the server, that data becomes the DEFAULT
>> value of the control as it is sent back down to the browser. Now,
>> when the browser sends that data back up to the server, the server
>> uses this data as the starting point from which to work. No data is
>> actually being stored (persisted) on the server.
>>
>> A good analogy of how client/server works:
>>
>> When you look up at the stars at night, you are seeing what they
>> looked like in the past. For all you know, the star you are looking
>> at doesn't even exist anymore.
>>
>> When you look at a web page (nice segway, huh?), you are seeing the
>> RESULTS of some server processing, but by the time you see those
>> results, the server has disconnected from you and moved on to handle
>> someone else's request. None of your data is stored on the server.
>> If you re-submit the page you are looking at in your browser, the
>> server must create a brand new instance of a page class, place band
>> new instances of controls on this page and attempt to restore certain
>> controls back to their previous values. Of course, the server
>> doesn't have any of these previous values, so it is up to the client
>> to post those values up to the server. That's what's happening with
>> your textbox example.
>>
>> The ONLY way to persist data on the server is to store that data
>> somewhere that the server can get a hold of it. As I mentioned in
>> my last reply: ViewState, the Cache, a database, cookies, a flat
>> file, etc. are all good candidates.
>>
>> As Marina suggested, a good understanding of client/server
>> communication as well as a good understanding of the Page class's
>> life-cycle would be a good place to start.
>>
>> Good luck,
>>
>> Scott
>>
>>
>>
>> "Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
>> news:%2****************@tk2msftngp13.phx.gbl...
>>> Thank you Marina. You are right about not understanding what is
>>> happening. Here is why I am not following. I placed a textbox on
>>> the same form using the same button, and was able to increment the
>>> value in the textbox. The code is below:
>>> Partial Class test
>>> Inherits System.Web.UI.Page
>>>
>>> Public i As Integer
>>>
>>> Protected Sub Page_Load(ByVal sender As Object, ByVal e As
>>> System.EventArgs) Handles Me.Load
>>>
>>> 'i = 0
>>>
>>> End Sub
>>>
>>> Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
>>> System.EventArgs) Handles Button2.Click
>>>
>>> 'i = i + 1
>>>
>>> 'MsgBox(i, MsgBoxStyle.Information)
>>>
>>> TextBox1.Text = TextBox1.Text + 1
>>>
>>> End Sub
>>>
>>> End Class
>>>
>>>
>>> If the page refreshes each time I click the button, then why doesn't
>>> the textbox lose its value? Maybe I'm not making sense, but its how
>>> I see it. ;)
>>>
>>> God Bless,
>>>
>>> Mark
>>>
>>>
>>>
>>>
>>>
>>> "Marina Levit [MVP]" <so*****@nospam.com> wrote in message
>>> news:eL**************@TK2MSFTNGP12.phx.gbl...
>>>> HTTP is stateless. This means on every request to the server, a new
>>>> Page object is created. Since it is always a new object, whatever
>>>> values you set on the old object, will not persist.
>>>>
>>>> However, even if everything worked as you imagine with there being
>>>> one instance of a Page object all the time, your code would still
>>>> not run as expected. This is because you are always setting i to 0
>>>> in Page_Load. So after the user clicks the button, i would be set
>>>> to 0, then incremented by 1 in the click handler. Then on the next
>>>> click the same thing would happen, and i would always be at 1.
>>>>
>>>> However, even if you fix your code to only set it to 0 in Page_Load
>>>> when it's not a postback (or just not do anything, since 0 is the
>>>> default for an integer anyway), your code would not work as you
>>>> expect for the reasons given in the beginning of the post.
>>>>
>>>> I recommend you get a book on ASP.NET and do some reading about how
>>>> it all works before proceeding much further. Without an understand
>>>> of the page lifecycle and the basic mechanics of ASP.NET it will be
>>>> hard to get far.
>>>>
>>>> "Mark A. Sam" <ms**@Plan-It-Earth.Net> wrote in message
>>>> news:uj**************@TK2MSFTNGP09.phx.gbl...
>>>>> Hello,
>>>>>
>>>>> I am using Visual Web Developer and decared a Public Variable in
>>>>> the Class section. I assigned a value in the load section, and on
>>>>> a button I set it up to increment, but it always delivers the same
>>>>> value, 1. When I increment the variable from the button,
>>>>> shouldn't it hold the new value? I also tried declaring the
>>>>> variable as a Friend, but it wasn't any more friendly. ;)
>>>>>
>>>>> Partial Class test
>>>>>
>>>>> Inherits System.Web.UI.Page
>>>>>
>>>>> Public i As Integer
>>>>>
>>>>> Protected Sub Page_Load(ByVal sender As Object, ByVal e As
>>>>> System.EventArgs) Handles Me.Load
>>>>>
>>>>> i = 0
>>>>>
>>>>> End Sub
>>>>>
>>>>> Protected Sub Button2_Click(ByVal sender As Object, ByVal e As
>>>>> System.EventArgs) Handles Button2.Click
>>>>>
>>>>> i = i + 1
>>>>>
>>>>> MsgBox(i, MsgBoxStyle.Information)
>>>>>
>>>>> End Sub
>>>>>
>>>>> End Class
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: David Casey |
last post by:
I'm working on a program for my C++ class and have it all written and
working except for one part. I need to compare two numeric variables to
determine decimal accuracy between them. For example:...
|
by: N. Demos |
last post by:
Hello,
I'm learning ASP.NET, and am having a strange problem with some example
code from the book I'm using. The code increments and displays the value
stored in a session variable when the "Add"...
|
by: Daz |
last post by:
Hello.
Please could somebody explain to me a method for auto-incrementing a
variable name?
I need to append a number to the variable name as it's created as it
will be automated.
For...
|
by: pozz |
last post by:
In my software, there are some variables that represents some settings.
They usually are numerical variables: unsigned char (0..255),
signed char (-127..128), unsigned int (0..65535), signed int...
|
by: Elementary |
last post by:
I have a number of variables, e.g. X1, X2, X3, X4, X5.
I want to select only the ones that are non zero(there will only be 2 or 3 at any time), and record them as Y1, Y2 and Y3
I want to know...
| | |
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| | |
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
