473,698 Members | 2,643 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

ViewState Questions

neo
hi,

I am studying ASP.NET and have few questions -

1) The session ID and values of controls is stored in VIEWSTATE
variable. So now when we put EnableViewState ="false" in Page directive and
disable the session state in Web.Config the VIEWSTATE variable is still
maintained and stores some values. Can anyone tell what those values are
for, i.e what other info is stored in VIEWSTATE other than the session ID
and the control values ?

2) Even after we set EnableViewState to false for some server controls,
(e.g. ASP:TextBox) still their values are maintained after the server round
trips - Why ? Shouldn't they act like HTML controls - loosing their values
after trip to server ?

3) Now the viewstate contains the control values but what is the need for
this ? Because the controls values are sent with the POST method of the
form. Isn't this storing the same info twice on the page ? May be this is
needed for DataGrid controls which are implemented as Table tags and these
table tags are not controls so they are not sent with the form POST. ( and
so need to be stored in VIEWSTATE ). But still why store values of all the
controls (including those which are posted with the form ) ?

4) Can session ID be made to be stored in cookies rather than the VIEWSTATE
?

May be I am missing something basic here, plz advice.
Thanks.
Pravin.


Nov 18 '05 #1
10 2271

"neo" <wo*@yahoo.co m> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
hi,

I am studying ASP.NET and have few questions -

1) The session ID and values of controls is stored in VIEWSTATE
variable. So now when we put EnableViewState ="false" in Page directive and
disable the session state in Web.Config the VIEWSTATE variable is still
maintained and stores some values. Can anyone tell what those values are
for, i.e what other info is stored in VIEWSTATE other than the session ID
and the control values ?

2) Even after we set EnableViewState to false for some server controls,
(e.g. ASP:TextBox) still their values are maintained after the server round trips - Why ? Shouldn't they act like HTML controls - loosing their values
after trip to server ?
ViewState is not responsible for textboxes (and many of the other standard
controls) holding on to their values after a postback. A textbox, checkbox,
radio button, password box, text area or hidden form field need no .NET
assistance to submit their data to the server (HTML Post takes care of
that). When those values arrive at the server and the server is getting the
page ready for its postback delivery back to the client, the sever just
takes the posted values and makes those values become the default values of
the controls for the trip down (i.e. <INPUT TYPE="Text" VALUE="value posted
during last rendering">).

So, for many of the "HTML-like" server controls, viewstate is not what's
responsible for them maintaining their state across postbacks.

Where viewstate would come in would be for a drop down list box. Viewstate
isn't needed to remember what from the list was chosen, it's used to
remember the whole list in the first place.

3) Now the viewstate contains the control values but what is the need for
this ? Because the controls values are sent with the POST method of the
form. Isn't this storing the same info twice on the page ?
As mentioned above, those controls that don't need viewstate because they
are using POST, don't have their values stored in viewstate to begin with.
If you turn on page tracing and look at the Control Tree section, you will
see this.
May be this is
needed for DataGrid controls which are implemented as Table tags and these
table tags are not controls so they are not sent with the form POST. ( and
so need to be stored in VIEWSTATE ). But still why store values of all the
controls (including those which are posted with the form ) ?

4) Can session ID be made to be stored in cookies rather than the VIEWSTATE ?

May be I am missing something basic here, plz advice.
Thanks.
Pravin.

Nov 18 '05 #2
In addition to Scott post,

If you really want to know what stored in the ViewState data even if you
got empty page with enableviewstate set to false you have to investigate
a little bit.
1) Override SavePageStateTo PersistenceMedi um method and inspect in
runtime the value of the First parameter of triplex object that pass as
parameter.

2) Follow the post in my blog on “Behind the scenes of ASPX files” and
open the class that asp.net generate for your ASPX file. Scroll to
GetTypeHashCode function and check out the return value.

Yes, this is the value that saved by the page in Viewstate.
GetTypeHashCode return hash code that is unique to the Page object's
control hierarchy.
Natty Gur[MVP]

blog : http://weblogs.asp.net/ngur
Mobile: +972-(0)58-888377
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 18 '05 #3
Comments inline:

"neo" <wo*@yahoo.co m> wrote in message
news:#M******** ******@tk2msftn gp13.phx.gbl...
1) The session ID and values of controls is stored in VIEWSTATE
variable. So now when we put EnableViewState ="false" in Page directive and
disable the session state in Web.Config the VIEWSTATE variable is still
maintained and stores some values. Can anyone tell what those values are
for, i.e what other info is stored in VIEWSTATE other than the session ID
and the control values ?
First of all, the Session ID is NOT stored in ViewState. It is stored either
in a cookie, or in URL QueryString. It is very important to discriminate
between ViewState and Session State. Session variables are stored in memory
(or in a database) on the server. ViewState stores values in a hidden form
field on the Page. Sessions time out. As ViewState variables are in the HTML
of a web document, they do NOT expire. By default, Control values (of
certain controls) are the only thing stored in ViewState. However, you can
also programmaticall y add variables to any Page's ViewState.
2) Even after we set EnableViewState to false for some server controls,
(e.g. ASP:TextBox) still their values are maintained after the server round trips - Why ? Shouldn't they act like HTML controls - loosing their values
after trip to server ?
Any Control that has ViewState disabled should not be able to maintain its
State. I don't know what the problem is with your app.
3) Now the viewstate contains the control values but what is the need for
this ? Because the controls values are sent with the POST method of the
form. Isn't this storing the same info twice on the page ? May be this is
needed for DataGrid controls which are implemented as Table tags and these
table tags are not controls so they are not sent with the form POST. ( and
so need to be stored in VIEWSTATE ). But still why store values of all the
controls (including those which are posted with the form ) ?
There are any number of reasons for this. ViewState has a specific purpose,
and it is NOT for storing the CURRENT client-side value of a Control. It is
for storing the LAST value the Control had prior to PostBack. It can also be
used on the server side to find out if the value in a Control has changed
since the last PostBack, which can certainly come in handy. And so on.
4) Can session ID be made to be stored in cookies rather than the

VIEWSTATE

Since Session ID is already NOT stored in ViewState, but by default is
stored in a Cookie, this question is moot.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
Nov 18 '05 #4
> Any Control that has ViewState disabled should not be able to maintain its
State. I don't know what the problem is with your app.
That's not true. As stated in my last post, many of the HTML-like controls
(textboxes, checkboxes, radiobuttons, etc.) don't use ViewState to hold
their values in the first place, so disabling ViewState would not affect the
control's ability to retain its state.

If you don't want a control to maintain its state, you could just use an
HTML control, rather than a Web Form control.
3) Now the viewstate contains the control values but what is the need for this ? Because the controls values are sent with the POST method of the
form. Isn't this storing the same info twice on the page ? May be this is needed for DataGrid controls which are implemented as Table tags and these table tags are not controls so they are not sent with the form POST. ( and so need to be stored in VIEWSTATE ). But still why store values of all the controls (including those which are posted with the form ) ?


There are any number of reasons for this. ViewState has a specific

purpose, and it is NOT for storing the CURRENT client-side value of a Control. It is for storing the LAST value the Control had prior to PostBack. It can also be used on the server side to find out if the value in a Control has changed
since the last PostBack, which can certainly come in handy. And so on.


Well, again, not always. Those controls that POST their values to the
server and have an HTML mechanism for setting a default value (value="?",
Checked, etc.), don't also write their last value into ViewState. ViewState
is generally for holding the values of the more "rich" controls like
DataGrids, ListBoxes and such.
Nov 18 '05 #5
I'm not looking for an argument. I stand by what I said.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Scott M." <s-***@BADSPAMsnet .net> wrote in message
news:ef******** ******@TK2MSFTN GP10.phx.gbl...
Any Control that has ViewState disabled should not be able to maintain its
State. I don't know what the problem is with your app.
That's not true. As stated in my last post, many of the HTML-like

controls (textboxes, checkboxes, radiobuttons, etc.) don't use ViewState to hold
their values in the first place, so disabling ViewState would not affect the control's ability to retain its state.

If you don't want a control to maintain its state, you could just use an
HTML control, rather than a Web Form control.
3) Now the viewstate contains the control values but what is the need for this ? Because the controls values are sent with the POST method of the form. Isn't this storing the same info twice on the page ? May be this is needed for DataGrid controls which are implemented as Table tags and these table tags are not controls so they are not sent with the form POST. ( and so need to be stored in VIEWSTATE ). But still why store values of all the controls (including those which are posted with the form ) ?
There are any number of reasons for this. ViewState has a specific

purpose,
and it is NOT for storing the CURRENT client-side value of a Control. It

is
for storing the LAST value the Control had prior to PostBack. It can also be
used on the server side to find out if the value in a Control has
changed since the last PostBack, which can certainly come in handy. And so on.


Well, again, not always. Those controls that POST their values to the
server and have an HTML mechanism for setting a default value (value="?",
Checked, etc.), don't also write their last value into ViewState.

ViewState is generally for holding the values of the more "rich" controls like
DataGrids, ListBoxes and such.

Nov 18 '05 #6
I'm not trying to give you an argument. I'm trying to point out an
erroneous statement.

Have you ever taken a Web Form textbox, set EnableViewState to False and
seen what happens? Or have you ever turned on page level tracing for a page
with such controls and seen what the ViewState column shows during a non
postback and a postback?

If so, you'd know that this control was never using ViewState to begin with.
Knowing that, it is easier to understand why turning ViewState off wouldn't
affect the behavior.

I don't know how you could "stand by" your assertion that "Any Control that
has ViewState disabled should not be able to maintain its State."

But it does become clear why you would say "I don't know what the problem is
with your app.".

"Kevin Spencer" <ke***@takempis .com> wrote in message
news:uB******** ******@TK2MSFTN GP09.phx.gbl...
I'm not looking for an argument. I stand by what I said.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Scott M." <s-***@BADSPAMsnet .net> wrote in message
news:ef******** ******@TK2MSFTN GP10.phx.gbl...
Any Control that has ViewState disabled should not be able to maintain its State. I don't know what the problem is with your app.


That's not true. As stated in my last post, many of the HTML-like

controls
(textboxes, checkboxes, radiobuttons, etc.) don't use ViewState to hold
their values in the first place, so disabling ViewState would not affect

the
control's ability to retain its state.

If you don't want a control to maintain its state, you could just use an
HTML control, rather than a Web Form control.
> 3) Now the viewstate contains the control values but what is the
need
for
> this ? Because the controls values are sent with the POST method of the > form. Isn't this storing the same info twice on the page ? May be
this is
> needed for DataGrid controls which are implemented as Table tags and

these
> table tags are not controls so they are not sent with the form POST.
( and
> so need to be stored in VIEWSTATE ). But still why store values of
all the
> controls (including those which are posted with the form ) ?

There are any number of reasons for this. ViewState has a specific

purpose,
and it is NOT for storing the CURRENT client-side value of a Control.
It is
for storing the LAST value the Control had prior to PostBack. It can also
be
used on the server side to find out if the value in a Control has

changed since the last PostBack, which can certainly come in handy. And so on.


Well, again, not always. Those controls that POST their values to the
server and have an HTML mechanism for setting a default value

(value="?", Checked, etc.), don't also write their last value into ViewState.

ViewState
is generally for holding the values of the more "rich" controls like
DataGrids, ListBoxes and such.


Nov 18 '05 #7
JD
> Have you ever taken a Web Form textbox, set EnableViewState to False and
seen what happens? Or have you ever turned on page level tracing for a page with such controls and seen what the ViewState column shows during a non
postback and a postback?

If so, you'd know that this control was never using ViewState to begin with. Knowing that, it is easier to understand why turning ViewState off wouldn't affect the behavior.
Looking at the IL for textbox, it does indeed use viewstate.

..method public hidebysig newslot specialname virtual
instance void set_Text(string 'value') cil managed
{
// Code size 18 (0x12)
.maxstack 8
IL_0000: ldarg.0
IL_0001: callvirt instance class System.Web.UI.S tateBag
System.Web.UI.C ontrol::get_Vie wState()
IL_0006: ldstr "Text"
IL_000b: ldarg.1
IL_000c: callvirt instance void
System.Web.UI.S tateBag::set_It em(string,

object)
IL_0011: ret
} // end of method TextBox::set_Te xt
Does it absolutely need it? probably not. Previous values (viewstate) and
current values (post back data) are used to determine changed events. I just
did an experiment where viewstate for textbox was turned on, the text
changed event fires only when the text actually changes. Turn off viewstate,
and the text changed event fires on every postback.

JD

"Scott M." <s-***@BADSPAMsnet .net> wrote in message
news:#2******** ******@TK2MSFTN GP09.phx.gbl... I'm not trying to give you an argument. I'm trying to point out an
erroneous statement.

Have you ever taken a Web Form textbox, set EnableViewState to False and
seen what happens? Or have you ever turned on page level tracing for a page with such controls and seen what the ViewState column shows during a non
postback and a postback?

If so, you'd know that this control was never using ViewState to begin with. Knowing that, it is easier to understand why turning ViewState off wouldn' t affect the behavior.

I don't know how you could "stand by" your assertion that "Any Control that has ViewState disabled should not be able to maintain its State."

But it does become clear why you would say "I don't know what the problem is with your app.".

"Kevin Spencer" <ke***@takempis .com> wrote in message
news:uB******** ******@TK2MSFTN GP09.phx.gbl...
I'm not looking for an argument. I stand by what I said.

--
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

"Scott M." <s-***@BADSPAMsnet .net> wrote in message
news:ef******** ******@TK2MSFTN GP10.phx.gbl...
> Any Control that has ViewState disabled should not be able to maintain
its
> State. I don't know what the problem is with your app.

That's not true. As stated in my last post, many of the HTML-like controls
(textboxes, checkboxes, radiobuttons, etc.) don't use ViewState to
hold their values in the first place, so disabling ViewState would not affect
the
control's ability to retain its state.

If you don't want a control to maintain its state, you could just use
an HTML control, rather than a Web Form control.

> > 3) Now the viewstate contains the control values but what is the

need for
> > this ? Because the controls values are sent with the POST method of the
> > form. Isn't this storing the same info twice on the page ? May be this is
> > needed for DataGrid controls which are implemented as Table tags
and these
> > table tags are not controls so they are not sent with the form POST. ( and
> > so need to be stored in VIEWSTATE ). But still why store values of all the
> > controls (including those which are posted with the form ) ?
>
> There are any number of reasons for this. ViewState has a specific
purpose,
> and it is NOT for storing the CURRENT client-side value of a
Control.
It is
> for storing the LAST value the Control had prior to PostBack. It can

also
be
> used on the server side to find out if the value in a Control has

changed
> since the last PostBack, which can certainly come in handy. And so
on.
Well, again, not always. Those controls that POST their values to the
server and have an HTML mechanism for setting a default value

(value="?", Checked, etc.), don't also write their last value into ViewState.

ViewState
is generally for holding the values of the more "rich" controls like
DataGrids, ListBoxes and such.



Nov 18 '05 #8

"JD" <No@Where.com > wrote in message
news:es******** ******@TK2MSFTN GP12.phx.gbl...
Have you ever taken a Web Form textbox, set EnableViewState to False and
seen what happens? Or have you ever turned on page level tracing for a page
with such controls and seen what the ViewState column shows during a non
postback and a postback?

If so, you'd know that this control was never using ViewState to begin

with.
Knowing that, it is easier to understand why turning ViewState off

wouldn't
affect the behavior.


Looking at the IL for textbox, it does indeed use viewstate.

.method public hidebysig newslot specialname virtual
instance void set_Text(string 'value') cil managed
{
// Code size 18 (0x12)
.maxstack 8
IL_0000: ldarg.0
IL_0001: callvirt instance class System.Web.UI.S tateBag
System.Web.UI.C ontrol::get_Vie wState()
IL_0006: ldstr "Text"
IL_000b: ldarg.1
IL_000c: callvirt instance void
System.Web.UI.S tateBag::set_It em(string,

object)
IL_0011: ret
} // end of method TextBox::set_Te xt
Does it absolutely need it? probably not. Previous values (viewstate) and
current values (post back data) are used to determine changed events. I

just did an experiment where viewstate for textbox was turned on, the text
changed event fires only when the text actually changes. Turn off viewstate, and the text changed event fires on every postback.

JD


Thanks JD. So, I guess the moral of the story is that for controls that
post their data and hold their values because the server planted the value
into the default value attribute, ViewState is used only to determine if a
change event fires?
Nov 18 '05 #9
JD
> Thanks JD. So, I guess the moral of the story is that for controls that
post their data and hold their values because the server planted the value
into the default value attribute, ViewState is used only to determine if a
change event fires?
Taking a closer look, it seems like properties are saved in viewstate also.
I just set the width of textbox to 1000px in the not postback section of
page load, set viewstate off, and the textbox does not remember it. Set
viewstate to on and it can retain its width setting.
"Scott M." <s-***@BADSPAMsnet .net> wrote in message
news:#3******** ******@tk2msftn gp13.phx.gbl...
"JD" <No@Where.com > wrote in message
news:es******** ******@TK2MSFTN GP12.phx.gbl...
Have you ever taken a Web Form textbox, set EnableViewState to False and seen what happens? Or have you ever turned on page level tracing for a
page
with such controls and seen what the ViewState column shows during a
non postback and a postback?

If so, you'd know that this control was never using ViewState to begin

with.
Knowing that, it is easier to understand why turning ViewState off

wouldn't
affect the behavior.


Looking at the IL for textbox, it does indeed use viewstate.

.method public hidebysig newslot specialname virtual
instance void set_Text(string 'value') cil managed
{
// Code size 18 (0x12)
.maxstack 8
IL_0000: ldarg.0
IL_0001: callvirt instance class System.Web.UI.S tateBag
System.Web.UI.C ontrol::get_Vie wState()
IL_0006: ldstr "Text"
IL_000b: ldarg.1
IL_000c: callvirt instance void
System.Web.UI.S tateBag::set_It em(string,

object)
IL_0011: ret
} // end of method TextBox::set_Te xt
Does it absolutely need it? probably not. Previous values (viewstate)

and current values (post back data) are used to determine changed events. I

just
did an experiment where viewstate for textbox was turned on, the text
changed event fires only when the text actually changes. Turn off

viewstate,
and the text changed event fires on every postback.

JD


Thanks JD. So, I guess the moral of the story is that for controls that
post their data and hold their values because the server planted the value
into the default value attribute, ViewState is used only to determine if a
change event fires?

Nov 18 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
2334
by: Trevor Andrew | last post by:
Hi There, I have posted something previously regarding this issue, but I think I have some more concise questions to ask, and would like to get further feedback on this issue. Firstly the background. I have a small ASP.NET application under development. I'm using VS 2002 with Framework 1.1. One of the pages is a "resources" page that contains a list-box of various RSS feeds I am interested in surveying. As you select the different RSS...
2
2818
by: Ben Rush | last post by:
Hello World, Okay, I have spent the day browsing the newsgroups and reading up on article after article concerning ViewState corruption and so forth, and I have a couple questions. We intermittantly get the following exception - EXCEPTION MESSAGE: The viewstate is invalid for this page and might be corrupted. STACK TRACE:
8
4276
by: Invalidlastname | last post by:
Hi, We are developing an asp.net application, and we dynamically created certain literal controls to represent some read-only text for certain editable controls. However, recently we found an issue which is related to the repeater. In the code shown below, if I call Repeater1.Controls.Count in the OnInit (the code fragment was highlighted in yellow) , the viewstate for the repeater will be lost during the postback. You can re-produce this...
1
1706
by: Sky | last post by:
Although I've been using C# for the last month or so, and accepting out of blind faith the ViewState, I do have some nagging questions about it... can you help verify the following statements? Application is across all sessions. Session is across all pages. ViewState is sort of like Session, but for only one page. <-- Correct statement? Session is stored between page requests, somewhere in mem or IIS files --
3
1170
by: foldface | last post by:
Hi I have only just become aware that form values posted to the server don't need to be preserved in viewstate because asp.net preserves them anyway separately from this. 2 questions (1) What is the mechanism that preserves them? (Purely for academic interest) (2) I have a property on a control that is added to the viewstate. With trace on and some code that shows the contents of the viewstate I see that information both in the viewstate...
4
6726
by: Chuck Ritzke | last post by:
Hi, I've searched the newsgroup and other sources to understand how to handle runtime controls and see I'm not the only one who's confused, but I'm still not quite sure of the best way to handle from all the various explanations/answers. I'm attempting the typical scenario... I create a variable number of controls at runtime based on parameters from a database.
0
1454
by: S.Sigal | last post by:
Hello: I've been trying to 'organize' the layout of my larger controls by moving variables into instances of subclasses...but it just dawned on me that I might be opening a real can of worms due to StateBag serialization... If ViewState serialization is optimized for Int32, Bool, String, Color, and arrays thereof... what happens when I want to serialize the instance of a class that contains an Int32, Bool String, or Color?
7
2041
by: et | last post by:
I'm not sure I understand the use of the ViewState. Do I understand correctly that values of controls are automatically held in a hidden control called ViewState? If so, then why can't we get them, or how do we get that value? I always have to set the ViewState("FirstName") = txtBox.text myself before a postback is done, otherwise, the value of ViewState("FirstName") is always empty; there doesn't seem to be a way to retrieve that...
0
1660
by: Walter | last post by:
Hi, can someone please help me with my custom control viewstate problem....I haven't slept for hours trying to get this fixed. I am making two custom controls which will be included on a single page. For now, I will call them box1 and box2. Each box has a panel and will display a list of link buttons on the panel. When the page loads for the first time, box1 will call the database and create a list of linkbuttons and each link button has...
0
8611
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9170
Oralloy
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9031
jinu1996
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8904
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 Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
7741
agi2029
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, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5867
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 then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4372
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 last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
3052
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
2007
bsmnconsultancy
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 can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.