user perspective vb.net = vb inside a browser?

[migue]

way below newbie level:

I know nothing about .Net. Have a VB6 client-server application (business
app, inventory, purchasing, invoicing, etc.) and am considering converting
it to VB.Net at a customer's request. The goal is to have access to the
application from remote locations without the need to install anything on
the client.

Question 1:
How will the user's desktop experience change using .Net vs. VB? i.e. will
the application now run inside a browser or will it run as a full-window of
it's own? Do controls (drop-downs, radio buttons, etc.) work essentially the
same way from a user's perspective?

Question 2:
Does the application still behave as it currently does, i.e. as a "true"
windows application vs. a web page. e.g. triggers such as leave field to
perform validation against db, etc.

Question 3:
Assuming the application is deployed for access over the Internet, what is
the minimum connection speed to achieve reasonable throughput. i.e. when a
user leaves a field, I currently validate the entered data against a
database table, I perform sqlread to lookup the value in a table. Is that
still a valid method of doing things or do we return to the old mainframe
(and html web page) methodology of page level validation only?

thanks

[migue]

Re: user perspective vb.net = vb inside a browser?

Mark,

Thank you! that was the most straightforward answer I have found to my basic
query. I am quite familiar with ASP and wrote some applications in it (in
the long distant, ancient past....about 4 years ago). However, I found that
ASP does not provide the rich user interface that intranet users expect. I
thought that what .Net and the framework provided me was a way of runing VB
remotely accross the internet....I guess not, still ASP as the front end....

thanks


"Mark" <f1fannz@hotmai l.com> wrote in message
news:#5DD23jVDH A.2344@TK2MSFTN GP09.phx.gbl...[color=blue]
> Hi
> I will try and answer some questions to get you in the right direstion but
> you have a lot of reading to do :)
>
> .NET is a framework not a development language. The framework is a huge
> library (probably the wrong word) of classes that are available to you,
> hiding most of the operating system stuff we used to have to do with[/color]
API's.[color=blue]
> VB.NET is a language with its own syntax. By referencing the .NET[/color]
framework[color=blue]
> you can use the classes. You DO NOT NEED Visual Studio.NET or VB.NET to
> write the code - notepad will do (but trust me it is very slow and hard to
> use it this way) but these IDE's do give you all the benefits of
> intellisense and more.
>
> To deploy a .NET application the client needs to have the .NET Framework
> runtime (dotnetfx.exe) installed. This goes for a web server too for
> ASP.NET apps.
>
> Your VB6 app will (with a wee bit of manipulation) upgrade to VB.NET.[/color]
..NET[color=blue]
> give VB programmers full OO benefits such as Inheritence and polymorphism
> etc. that they didnt have before. Once you have upgraded it to VB.NET you
> can install the framework on each client (this is once per client not once
> per .NET app installed on the client) and it will run as before[/color]
(hopefully).[color=blue]
> i.e. a rich windows gui.
>
> What your questions imply is a change of use (and architecture) of your
> current app. No language change will do that for you as you are wanting[/color]
to[color=blue]
> use it differently than you previously planned.
>
> You can achieve your result in a number of ways. First, as .NET does not
> require registration (i.e. no more dll hell) you can use a touchless[/color]
deploy[color=blue]
> so all clients can get a rich (windows) gui application (even a thick
> client) from a central point without them knowing. Secondly you could
> install a small thin client UI on each client and get them to remote to[/color]
the[color=blue]
> other assemblies using .NET remoting (sounds like your preferred option).
>
> Alternatively you could write an ASP .NET application for the UI on the
> client side and have the rest of the app in normal .NET someplace central.
> The is a downside to this as not as rich functionality as with a rich
> windows GUI. That decision depends on whether the access is by people on[/color]
an[color=blue]
> intranet or internet etc.
>
> In terms of speed of access etc, using .NET remoting is very light on
> traffic and by the sound of your application an ADO.NET dataset would do[/color]
for[color=blue]
> the data movement, which is just xml files so nice and light on bandwidth.
>
> Read up on .NET, ADO.NET and .NET remoting.
>
> as for your other posting about applications our web site is being[/color]
rewritten[color=blue]
> in C#.NET and VB.NET now so go see an app in use at www.abc123it.com (bear
> in mind that it isnt finished yet). We have been writing .NET apps in VB
> and C# for 2 years in commercial environments and have not written a[/color]
Visual[color=blue]
> Studio 6 app in all that time as we (and our customers) prefer .NET
>
> Hope this helps
> Mark
>
> "migue" <mfoncerrada@ho tmail.com> wrote in message
> news:uq%234eQjV DHA.1280@tk2msf tngp13.phx.gbl. ..[color=green]
> > way below newbie level:
> >
> > I know nothing about .Net. Have a VB6 client-server application[/color][/color]
(business[color=blue][color=green]
> > app, inventory, purchasing, invoicing, etc.) and am considering[/color][/color]
converting[color=blue][color=green]
> > it to VB.Net at a customer's request. The goal is to have access to the
> > application from remote locations without the need to install anything[/color][/color]
on[color=blue][color=green]
> > the client.
> >
> > Question 1:
> > How will the user's desktop experience change using .Net vs. VB? i.e.[/color][/color]
will[color=blue][color=green]
> > the application now run inside a browser or will it run as a full-window[/color]
> of[color=green]
> > it's own? Do controls (drop-downs, radio buttons, etc.) work essentially[/color]
> the[color=green]
> > same way from a user's perspective?
> >
> > Question 2:
> > Does the application still behave as it currently does, i.e. as a "true"
> > windows application vs. a web page. e.g. triggers such as leave field to
> > perform validation against db, etc.
> >
> > Question 3:
> > Assuming the application is deployed for access over the Internet, what[/color][/color]
is[color=blue][color=green]
> > the minimum connection speed to achieve reasonable throughput. i.e. when[/color][/color]
a[color=blue][color=green]
> > user leaves a field, I currently validate the entered data against a
> > database table, I perform sqlread to lookup the value in a table. Is[/color][/color]
that[color=blue][color=green]
> > still a valid method of doing things or do we return to the old[/color][/color]
mainframe[color=blue][color=green]
> > (and html web page) methodology of page level validation only?
> >
> > thanks
> >
> >[/color]
>
>[/color]

[migue]

Re: user perspective vb.net = vb inside a browser?

Mark,

Thank you! that was the most straightforward answer I have found to my basic
query. I am quite familiar with ASP and wrote some applications in it (in
the long distant, ancient past....about 4 years ago). However, I found that
ASP does not provide the rich user interface that intranet users expect. I
thought that what .Net and the framework provided me was a way of runing VB
remotely accross the internet....I guess not, still ASP as the front end....

thanks


"Mark" <f1fannz@hotmai l.com> wrote in message
news:#5DD23jVDH A.2344@TK2MSFTN GP09.phx.gbl...[color=blue]
> Hi
> I will try and answer some questions to get you in the right direstion but
> you have a lot of reading to do :)
>
> .NET is a framework not a development language. The framework is a huge
> library (probably the wrong word) of classes that are available to you,
> hiding most of the operating system stuff we used to have to do with[/color]
API's.[color=blue]
> VB.NET is a language with its own syntax. By referencing the .NET[/color]
framework[color=blue]
> you can use the classes. You DO NOT NEED Visual Studio.NET or VB.NET to
> write the code - notepad will do (but trust me it is very slow and hard to
> use it this way) but these IDE's do give you all the benefits of
> intellisense and more.
>
> To deploy a .NET application the client needs to have the .NET Framework
> runtime (dotnetfx.exe) installed. This goes for a web server too for
> ASP.NET apps.
>
> Your VB6 app will (with a wee bit of manipulation) upgrade to VB.NET.[/color]
..NET[color=blue]
> give VB programmers full OO benefits such as Inheritence and polymorphism
> etc. that they didnt have before. Once you have upgraded it to VB.NET you
> can install the framework on each client (this is once per client not once
> per .NET app installed on the client) and it will run as before[/color]
(hopefully).[color=blue]
> i.e. a rich windows gui.
>
> What your questions imply is a change of use (and architecture) of your
> current app. No language change will do that for you as you are wanting[/color]
to[color=blue]
> use it differently than you previously planned.
>
> You can achieve your result in a number of ways. First, as .NET does not
> require registration (i.e. no more dll hell) you can use a touchless[/color]
deploy[color=blue]
> so all clients can get a rich (windows) gui application (even a thick
> client) from a central point without them knowing. Secondly you could
> install a small thin client UI on each client and get them to remote to[/color]
the[color=blue]
> other assemblies using .NET remoting (sounds like your preferred option).
>
> Alternatively you could write an ASP .NET application for the UI on the
> client side and have the rest of the app in normal .NET someplace central.
> The is a downside to this as not as rich functionality as with a rich
> windows GUI. That decision depends on whether the access is by people on[/color]
an[color=blue]
> intranet or internet etc.
>
> In terms of speed of access etc, using .NET remoting is very light on
> traffic and by the sound of your application an ADO.NET dataset would do[/color]
for[color=blue]
> the data movement, which is just xml files so nice and light on bandwidth.
>
> Read up on .NET, ADO.NET and .NET remoting.
>
> as for your other posting about applications our web site is being[/color]
rewritten[color=blue]
> in C#.NET and VB.NET now so go see an app in use at www.abc123it.com (bear
> in mind that it isnt finished yet). We have been writing .NET apps in VB
> and C# for 2 years in commercial environments and have not written a[/color]
Visual[color=blue]
> Studio 6 app in all that time as we (and our customers) prefer .NET
>
> Hope this helps
> Mark
>
> "migue" <mfoncerrada@ho tmail.com> wrote in message
> news:uq%234eQjV DHA.1280@tk2msf tngp13.phx.gbl. ..[color=green]
> > way below newbie level:
> >
> > I know nothing about .Net. Have a VB6 client-server application[/color][/color]
(business[color=blue][color=green]
> > app, inventory, purchasing, invoicing, etc.) and am considering[/color][/color]
converting[color=blue][color=green]
> > it to VB.Net at a customer's request. The goal is to have access to the
> > application from remote locations without the need to install anything[/color][/color]
on[color=blue][color=green]
> > the client.
> >
> > Question 1:
> > How will the user's desktop experience change using .Net vs. VB? i.e.[/color][/color]
will[color=blue][color=green]
> > the application now run inside a browser or will it run as a full-window[/color]
> of[color=green]
> > it's own? Do controls (drop-downs, radio buttons, etc.) work essentially[/color]
> the[color=green]
> > same way from a user's perspective?
> >
> > Question 2:
> > Does the application still behave as it currently does, i.e. as a "true"
> > windows application vs. a web page. e.g. triggers such as leave field to
> > perform validation against db, etc.
> >
> > Question 3:
> > Assuming the application is deployed for access over the Internet, what[/color][/color]
is[color=blue][color=green]
> > the minimum connection speed to achieve reasonable throughput. i.e. when[/color][/color]
a[color=blue][color=green]
> > user leaves a field, I currently validate the entered data against a
> > database table, I perform sqlread to lookup the value in a table. Is[/color][/color]
that[color=blue][color=green]
> > still a valid method of doing things or do we return to the old[/color][/color]
mainframe[color=blue][color=green]
> > (and html web page) methodology of page level validation only?
> >
> > thanks
> >
> >[/color]
>
>[/color]

[Mark]

Re: user perspective vb.net = vb inside a browser?

You dont have to use ASP (by the way ASP .NET is wayyyyyyyy better than
ASP).

From what i have read of your situation i would deploy a very thin client of
just the windows forms on each client (and there are ways of doing that
without them knowing too - you can do a touchless deploy from a central
server each time they click a link on their desktop just like a web page).
However they will have full Windows GUI and controls etc but the rest of the
application is on remote servers within the intranet (extranet, internet or
whatever). The rest works on the same principle as ASP (ie some form of
service delivers the information needed to the client) but you have a number
of options (and in your case for speed etc. .NET remoting through a windows
service would be the way i would probably go).

ASP is used for web pages when you dont know the client. If you know and
have some control over the client then deliver Windows forms to them for a
rich GUI but use remoting so you have control and security over your system

Hope that helps
"migue" <mfoncerrada@ho tmail.com> wrote in message
news:%23kwiRnkV DHA.3924@tk2msf tngp13.phx.gbl. ..[color=blue]
> Mark,
>
> Thank you! that was the most straightforward answer I have found to my[/color]
basic[color=blue]
> query. I am quite familiar with ASP and wrote some applications in it (in
> the long distant, ancient past....about 4 years ago). However, I found[/color]
that[color=blue]
> ASP does not provide the rich user interface that intranet users expect.[/color]
I[color=blue]
> thought that what .Net and the framework provided me was a way of runing[/color]
VB[color=blue]
> remotely accross the internet....I guess not, still ASP as the front[/color]
end....[color=blue]
>
> thanks
>
>
> "Mark" <f1fannz@hotmai l.com> wrote in message
> news:#5DD23jVDH A.2344@TK2MSFTN GP09.phx.gbl...[color=green]
> > Hi
> > I will try and answer some questions to get you in the right direstion[/color][/color]
but[color=blue][color=green]
> > you have a lot of reading to do :)
> >
> > .NET is a framework not a development language. The framework is a huge
> > library (probably the wrong word) of classes that are available to you,
> > hiding most of the operating system stuff we used to have to do with[/color]
> API's.[color=green]
> > VB.NET is a language with its own syntax. By referencing the .NET[/color]
> framework[color=green]
> > you can use the classes. You DO NOT NEED Visual Studio.NET or VB.NET to
> > write the code - notepad will do (but trust me it is very slow and hard[/color][/color]
to[color=blue][color=green]
> > use it this way) but these IDE's do give you all the benefits of
> > intellisense and more.
> >
> > To deploy a .NET application the client needs to have the .NET Framework
> > runtime (dotnetfx.exe) installed. This goes for a web server too for
> > ASP.NET apps.
> >
> > Your VB6 app will (with a wee bit of manipulation) upgrade to VB.NET.[/color]
> .NET[color=green]
> > give VB programmers full OO benefits such as Inheritence and[/color][/color]
polymorphism[color=blue][color=green]
> > etc. that they didnt have before. Once you have upgraded it to VB.NET[/color][/color]
you[color=blue][color=green]
> > can install the framework on each client (this is once per client not[/color][/color]
once[color=blue][color=green]
> > per .NET app installed on the client) and it will run as before[/color]
> (hopefully).[color=green]
> > i.e. a rich windows gui.
> >
> > What your questions imply is a change of use (and architecture) of your
> > current app. No language change will do that for you as you are wanting[/color]
> to[color=green]
> > use it differently than you previously planned.
> >
> > You can achieve your result in a number of ways. First, as .NET does[/color][/color]
not[color=blue][color=green]
> > require registration (i.e. no more dll hell) you can use a touchless[/color]
> deploy[color=green]
> > so all clients can get a rich (windows) gui application (even a thick
> > client) from a central point without them knowing. Secondly you could
> > install a small thin client UI on each client and get them to remote to[/color]
> the[color=green]
> > other assemblies using .NET remoting (sounds like your preferred[/color][/color]
option).[color=blue][color=green]
> >
> > Alternatively you could write an ASP .NET application for the UI on the
> > client side and have the rest of the app in normal .NET someplace[/color][/color]
central.[color=blue][color=green]
> > The is a downside to this as not as rich functionality as with a rich
> > windows GUI. That decision depends on whether the access is by people[/color][/color]
on[color=blue]
> an[color=green]
> > intranet or internet etc.
> >
> > In terms of speed of access etc, using .NET remoting is very light on
> > traffic and by the sound of your application an ADO.NET dataset would do[/color]
> for[color=green]
> > the data movement, which is just xml files so nice and light on[/color][/color]
bandwidth.[color=blue][color=green]
> >
> > Read up on .NET, ADO.NET and .NET remoting.
> >
> > as for your other posting about applications our web site is being[/color]
> rewritten[color=green]
> > in C#.NET and VB.NET now so go see an app in use at www.abc123it.com[/color][/color]
(bear[color=blue][color=green]
> > in mind that it isnt finished yet). We have been writing .NET apps in[/color][/color]
VB[color=blue][color=green]
> > and C# for 2 years in commercial environments and have not written a[/color]
> Visual[color=green]
> > Studio 6 app in all that time as we (and our customers) prefer .NET
> >
> > Hope this helps
> > Mark
> >
> > "migue" <mfoncerrada@ho tmail.com> wrote in message
> > news:uq%234eQjV DHA.1280@tk2msf tngp13.phx.gbl. ..[color=darkred]
> > > way below newbie level:
> > >
> > > I know nothing about .Net. Have a VB6 client-server application[/color][/color]
> (business[color=green][color=darkred]
> > > app, inventory, purchasing, invoicing, etc.) and am considering[/color][/color]
> converting[color=green][color=darkred]
> > > it to VB.Net at a customer's request. The goal is to have access to[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > application from remote locations without the need to install anything[/color][/color]
> on[color=green][color=darkred]
> > > the client.
> > >
> > > Question 1:
> > > How will the user's desktop experience change using .Net vs. VB? i.e.[/color][/color]
> will[color=green][color=darkred]
> > > the application now run inside a browser or will it run as a[/color][/color][/color]
full-window[color=blue][color=green]
> > of[color=darkred]
> > > it's own? Do controls (drop-downs, radio buttons, etc.) work[/color][/color][/color]
essentially[color=blue][color=green]
> > the[color=darkred]
> > > same way from a user's perspective?
> > >
> > > Question 2:
> > > Does the application still behave as it currently does, i.e. as a[/color][/color][/color]
"true"[color=blue][color=green][color=darkred]
> > > windows application vs. a web page. e.g. triggers such as leave field[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > perform validation against db, etc.
> > >
> > > Question 3:
> > > Assuming the application is deployed for access over the Internet,[/color][/color][/color]
what[color=blue]
> is[color=green][color=darkred]
> > > the minimum connection speed to achieve reasonable throughput. i.e.[/color][/color][/color]
when[color=blue]
> a[color=green][color=darkred]
> > > user leaves a field, I currently validate the entered data against a
> > > database table, I perform sqlread to lookup the value in a table. Is[/color][/color]
> that[color=green][color=darkred]
> > > still a valid method of doing things or do we return to the old[/color][/color]
> mainframe[color=green][color=darkred]
> > > (and html web page) methodology of page level validation only?
> > >
> > > thanks
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Mark]

Re: user perspective vb.net = vb inside a browser?

You dont have to use ASP (by the way ASP .NET is wayyyyyyyy better than
ASP).

From what i have read of your situation i would deploy a very thin client of
just the windows forms on each client (and there are ways of doing that
without them knowing too - you can do a touchless deploy from a central
server each time they click a link on their desktop just like a web page).
However they will have full Windows GUI and controls etc but the rest of the
application is on remote servers within the intranet (extranet, internet or
whatever). The rest works on the same principle as ASP (ie some form of
service delivers the information needed to the client) but you have a number
of options (and in your case for speed etc. .NET remoting through a windows
service would be the way i would probably go).

ASP is used for web pages when you dont know the client. If you know and
have some control over the client then deliver Windows forms to them for a
rich GUI but use remoting so you have control and security over your system

Hope that helps
"migue" <mfoncerrada@ho tmail.com> wrote in message
news:%23kwiRnkV DHA.3924@tk2msf tngp13.phx.gbl. ..[color=blue]
> Mark,
>
> Thank you! that was the most straightforward answer I have found to my[/color]
basic[color=blue]
> query. I am quite familiar with ASP and wrote some applications in it (in
> the long distant, ancient past....about 4 years ago). However, I found[/color]
that[color=blue]
> ASP does not provide the rich user interface that intranet users expect.[/color]
I[color=blue]
> thought that what .Net and the framework provided me was a way of runing[/color]
VB[color=blue]
> remotely accross the internet....I guess not, still ASP as the front[/color]
end....[color=blue]
>
> thanks
>
>
> "Mark" <f1fannz@hotmai l.com> wrote in message
> news:#5DD23jVDH A.2344@TK2MSFTN GP09.phx.gbl...[color=green]
> > Hi
> > I will try and answer some questions to get you in the right direstion[/color][/color]
but[color=blue][color=green]
> > you have a lot of reading to do :)
> >
> > .NET is a framework not a development language. The framework is a huge
> > library (probably the wrong word) of classes that are available to you,
> > hiding most of the operating system stuff we used to have to do with[/color]
> API's.[color=green]
> > VB.NET is a language with its own syntax. By referencing the .NET[/color]
> framework[color=green]
> > you can use the classes. You DO NOT NEED Visual Studio.NET or VB.NET to
> > write the code - notepad will do (but trust me it is very slow and hard[/color][/color]
to[color=blue][color=green]
> > use it this way) but these IDE's do give you all the benefits of
> > intellisense and more.
> >
> > To deploy a .NET application the client needs to have the .NET Framework
> > runtime (dotnetfx.exe) installed. This goes for a web server too for
> > ASP.NET apps.
> >
> > Your VB6 app will (with a wee bit of manipulation) upgrade to VB.NET.[/color]
> .NET[color=green]
> > give VB programmers full OO benefits such as Inheritence and[/color][/color]
polymorphism[color=blue][color=green]
> > etc. that they didnt have before. Once you have upgraded it to VB.NET[/color][/color]
you[color=blue][color=green]
> > can install the framework on each client (this is once per client not[/color][/color]
once[color=blue][color=green]
> > per .NET app installed on the client) and it will run as before[/color]
> (hopefully).[color=green]
> > i.e. a rich windows gui.
> >
> > What your questions imply is a change of use (and architecture) of your
> > current app. No language change will do that for you as you are wanting[/color]
> to[color=green]
> > use it differently than you previously planned.
> >
> > You can achieve your result in a number of ways. First, as .NET does[/color][/color]
not[color=blue][color=green]
> > require registration (i.e. no more dll hell) you can use a touchless[/color]
> deploy[color=green]
> > so all clients can get a rich (windows) gui application (even a thick
> > client) from a central point without them knowing. Secondly you could
> > install a small thin client UI on each client and get them to remote to[/color]
> the[color=green]
> > other assemblies using .NET remoting (sounds like your preferred[/color][/color]
option).[color=blue][color=green]
> >
> > Alternatively you could write an ASP .NET application for the UI on the
> > client side and have the rest of the app in normal .NET someplace[/color][/color]
central.[color=blue][color=green]
> > The is a downside to this as not as rich functionality as with a rich
> > windows GUI. That decision depends on whether the access is by people[/color][/color]
on[color=blue]
> an[color=green]
> > intranet or internet etc.
> >
> > In terms of speed of access etc, using .NET remoting is very light on
> > traffic and by the sound of your application an ADO.NET dataset would do[/color]
> for[color=green]
> > the data movement, which is just xml files so nice and light on[/color][/color]
bandwidth.[color=blue][color=green]
> >
> > Read up on .NET, ADO.NET and .NET remoting.
> >
> > as for your other posting about applications our web site is being[/color]
> rewritten[color=green]
> > in C#.NET and VB.NET now so go see an app in use at www.abc123it.com[/color][/color]
(bear[color=blue][color=green]
> > in mind that it isnt finished yet). We have been writing .NET apps in[/color][/color]
VB[color=blue][color=green]
> > and C# for 2 years in commercial environments and have not written a[/color]
> Visual[color=green]
> > Studio 6 app in all that time as we (and our customers) prefer .NET
> >
> > Hope this helps
> > Mark
> >
> > "migue" <mfoncerrada@ho tmail.com> wrote in message
> > news:uq%234eQjV DHA.1280@tk2msf tngp13.phx.gbl. ..[color=darkred]
> > > way below newbie level:
> > >
> > > I know nothing about .Net. Have a VB6 client-server application[/color][/color]
> (business[color=green][color=darkred]
> > > app, inventory, purchasing, invoicing, etc.) and am considering[/color][/color]
> converting[color=green][color=darkred]
> > > it to VB.Net at a customer's request. The goal is to have access to[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > application from remote locations without the need to install anything[/color][/color]
> on[color=green][color=darkred]
> > > the client.
> > >
> > > Question 1:
> > > How will the user's desktop experience change using .Net vs. VB? i.e.[/color][/color]
> will[color=green][color=darkred]
> > > the application now run inside a browser or will it run as a[/color][/color][/color]
full-window[color=blue][color=green]
> > of[color=darkred]
> > > it's own? Do controls (drop-downs, radio buttons, etc.) work[/color][/color][/color]
essentially[color=blue][color=green]
> > the[color=darkred]
> > > same way from a user's perspective?
> > >
> > > Question 2:
> > > Does the application still behave as it currently does, i.e. as a[/color][/color][/color]
"true"[color=blue][color=green][color=darkred]
> > > windows application vs. a web page. e.g. triggers such as leave field[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > perform validation against db, etc.
> > >
> > > Question 3:
> > > Assuming the application is deployed for access over the Internet,[/color][/color][/color]
what[color=blue]
> is[color=green][color=darkred]
> > > the minimum connection speed to achieve reasonable throughput. i.e.[/color][/color][/color]
when[color=blue]
> a[color=green][color=darkred]
> > > user leaves a field, I currently validate the entered data against a
> > > database table, I perform sqlread to lookup the value in a table. Is[/color][/color]
> that[color=green][color=darkred]
> > > still a valid method of doing things or do we return to the old[/color][/color]
> mainframe[color=green][color=darkred]
> > > (and html web page) methodology of page level validation only?
> > >
> > > thanks
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]