Speed of Development

[Simon Harvey]

Hi All,

I have a colleague that I wprk with that develops using ASP. I develop using
ASP.net.

He seems to make sites much faster than me and I am wondering if its because
of the two different technologies. I use codebehinds as standard

Does anyone else find that developing with ASP.net takes more work than asp.

I'm trying to avoid the conclusion that I'm just shit. Please help!

Simon

[Curt_C [MVP]]

"It depends"
ASP has the ease of being able to be tossed together fairly quickly, but
often it's very wrongly done (connections open, objects not destroyed, etc).
It also has the abiltity to not have to be compiled, this is good and bad.
ASP.NET, once you are familiar with the tools, is really just as quick. Down
the line as you start to reuse classes (etc) you will find you gain speed
too and pass him by.

--
Curt Christianson
Owner/Lead Developer, DF-Software
www.Darkfalz.com
"Simon Harvey" <si**********@the-web-works.co.uk> wrote in message
news:eL**************@TK2MSFTNGP11.phx.gbl...

Hi All,

I have a colleague that I wprk with that develops using ASP. I develop using ASP.net.

He seems to make sites much faster than me and I am wondering if its because of the two different technologies. I use codebehinds as standard

Does anyone else find that developing with ASP.net takes more work than asp.
I'm trying to avoid the conclusion that I'm just shit. Please help!

Simon

[George Ter-Saakov]

In ASP.
Connection does not need to be closed,
Object does not need to be destroyed.

The ASP.NET gives you so many abilities that you want to utilize them all.
So it takes project to take more time. Since it has more features.

Also i bet that his ASP forms do not have any validations.

George.

"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:OC**************@TK2MSFTNGP10.phx.gbl...

"It depends"
ASP has the ease of being able to be tossed together fairly quickly, but
often it's very wrongly done (connections open, objects not destroyed, etc). It also has the abiltity to not have to be compiled, this is good and bad.
ASP.NET, once you are familiar with the tools, is really just as quick. Down the line as you start to reuse classes (etc) you will find you gain speed
too and pass him by.

--
Curt Christianson
Owner/Lead Developer, DF-Software
www.Darkfalz.com
"Simon Harvey" <si**********@the-web-works.co.uk> wrote in message
news:eL**************@TK2MSFTNGP11.phx.gbl...

Hi All,

I have a colleague that I wprk with that develops using ASP. I develop

using

ASP.net.

He seems to make sites much faster than me and I am wondering if its

because

of the two different technologies. I use codebehinds as standard

Does anyone else find that developing with ASP.net takes more work than

asp.

I'm trying to avoid the conclusion that I'm just shit. Please help!

Simon

[Curt_C [MVP]]

> In ASP.

Connection does not need to be closed,
Object does not need to be destroyed.
not true really.... they will eventually go away, but in the meantime they
can, and will, eat major resources. It's always better to explicitly
close/kill them.
Also i bet that his ASP forms do not have any validations.

some of the ASP.NET ones are clientside though, and could be replicated in
ASP.
--
Curt Christianson
Owner/Lead Developer, DF-Software
www.Darkfalz.com

[Peter O'Reilly]

A programmer's level of experience is of much greater magnitude than which
development tool is used in terms of speed of development. (I'm talking
about same generation tools, e.g. not programming in assembler v. visual
basic)
Experience, along with how motivated your staff is, is even more so the case
within all that comprises a development project.

That said, I consider myself (equally) experienced with classic ASP and
ASP.NET. Comparing the two tools, in my experience using ASP.NET results in
much more rapid development due to intellisense, compiling, and true
debugging.
It's also a much more pleasurable experience.

--
Peter O'Reilly

[Alvin Bruney [MVP]]

dito

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/27cok
"Peter O'Reilly" <Pe***********@timeinc.com!N!O!.S!P!AM!> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

A programmer's level of experience is of much greater magnitude than which
development tool is used in terms of speed of development. (I'm talking
about same generation tools, e.g. not programming in assembler v. visual
basic)
Experience, along with how motivated your staff is, is even more so the
case
within all that comprises a development project.

That said, I consider myself (equally) experienced with classic ASP and
ASP.NET. Comparing the two tools, in my experience using ASP.NET results
in
much more rapid development due to intellisense, compiling, and true
debugging.
It's also a much more pleasurable experience.

--
Peter O'Reilly

[George Ter-Saakov]

I was talking about ASP (not ASP.NET)
In ASP objects are released when they go out of scope.

And there is not need to close connections or destroy objects.

There was a bug though in earlier versions of ADO when due to the cyclic
reference between recordset and connection the connection will not be closed
even if it goes out of scope.

George.
"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:uk**************@TK2MSFTNGP12.phx.gbl...

In ASP.
Connection does not need to be closed,
Object does not need to be destroyed.

not true really.... they will eventually go away, but in the meantime they
can, and will, eat major resources. It's always better to explicitly
close/kill them.

Also i bet that his ASP forms do not have any validations.

some of the ASP.NET ones are clientside though, and could be replicated in
ASP.
--
Curt Christianson
Owner/Lead Developer, DF-Software
www.Darkfalz.com

[Peter O'Reilly]

> There was a bug though in earlier versions of ADO when due to the cyclic

reference between recordset and connection the connection will not be closed even if it goes out of scope.

It was never a bug. In theory what you write should be the case (and is ok
for a very light load), but practice tells me otherwise. Some RDBMS like
Oracle 8,9i or MS Access (Jet) are much less forgiving than SQL Server with
respect to not closing connections and recordsets. I have found this to be
the case with IIS 4, 5, 5.1. Load testing a classic ASP application will
make this immediately apparent.

Microsoft/MSDN docs have consistently parroted all along that ADO recordsets
and connection objects should be explicitly closed. The same is true, even
more so for the .Net framework's datareader and connection objects. For
instance, it is not possible to (re)use another datareader on the connection
without closing the first. The result is an exception raised/run time
error.

--
Peter O'Reilly

[Kevin Spencer]

> And there is not need to close connections or destroy objects.

Hang on a second, George. Connections DO need to be closed, or disposed.
Setting objects to Nothing does Nothing. Closing Connections frees them up
for re-use.

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

"George Ter-Saakov" <no****@hotmail.com> wrote in message
news:eq**************@TK2MSFTNGP11.phx.gbl...

I was talking about ASP (not ASP.NET)
In ASP objects are released when they go out of scope.

And there is not need to close connections or destroy objects.

There was a bug though in earlier versions of ADO when due to the cyclic
reference between recordset and connection the connection will not be closed even if it goes out of scope.

George.
"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:uk**************@TK2MSFTNGP12.phx.gbl...

In ASP.
Connection does not need to be closed,
Object does not need to be destroyed.

not true really.... they will eventually go away, but in the meantime they can, and will, eat major resources. It's always better to explicitly
close/kill them.

Also i bet that his ASP forms do not have any validations.

some of the ASP.NET ones are clientside though, and could be replicated in ASP.
--
Curt Christianson
Owner/Lead Developer, DF-Software
www.Darkfalz.com

[George Ter-Saakov]

I am talking about ASP. Not ASP.NET.
In ASP.NET connection must be closed.
In ASP it's not necessary.

George.
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

And there is not need to close connections or destroy objects.
Hang on a second, George. Connections DO need to be closed, or disposed.
Setting objects to Nothing does Nothing. Closing Connections frees them up
for re-use.

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

"George Ter-Saakov" <no****@hotmail.com> wrote in message
news:eq**************@TK2MSFTNGP11.phx.gbl...

I was talking about ASP (not ASP.NET)
In ASP objects are released when they go out of scope.

And there is not need to close connections or destroy objects.

There was a bug though in earlier versions of ADO when due to the cyclic
reference between recordset and connection the connection will not be

closed

even if it goes out of scope.

George.
"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:uk**************@TK2MSFTNGP12.phx.gbl...

> In ASP.
> Connection does not need to be closed,
> Object does not need to be destroyed.
>
not true really.... they will eventually go away, but in the meantime they can, and will, eat major resources. It's always better to explicitly
close/kill them.

> Also i bet that his ASP forms do not have any validations.
>
some of the ASP.NET ones are clientside though, and could be

replicated in ASP.
--
Curt Christianson
Owner/Lead Developer, DF-Software
www.Darkfalz.com

[George Ter-Saakov]

Yes. Do the test. I tested with MS SQL.
Create an ASP page (not asp.net)

<%
Dim con
Set con = CreateObject("ADODB.Connection")
con.Open "Provider=SQLOLEDB.1;Password=test;Persist Security Info=True;User
ID=test;Initial Catalog=test;Data Source=test"
%>

Hit it couple times then go to Enterprise Managment Managment/Current
Activity/Process Info and you will see only one connection.
So it's not necessary to close connection in an APS page. ADO closes it for
you as soon as object goes out of scope.
MSDN is wirtten by people and usually not by developers who actually created
ADO.

BTW: It's practically impossible to write a clean ASP page which will close
connections in any case (exception, script timeout, ...)
George.
"Peter O'Reilly" <Pe***********@timeinc.com!N!O!.S!P!AM!> wrote in message
news:ej**************@TK2MSFTNGP10.phx.gbl...

There was a bug though in earlier versions of ADO when due to the cyclic
reference between recordset and connection the connection will not be closed

even if it goes out of scope.

It was never a bug. In theory what you write should be the case (and is

ok for a very light load), but practice tells me otherwise. Some RDBMS like
Oracle 8,9i or MS Access (Jet) are much less forgiving than SQL Server with respect to not closing connections and recordsets. I have found this to be the case with IIS 4, 5, 5.1. Load testing a classic ASP application will
make this immediately apparent.

Microsoft/MSDN docs have consistently parroted all along that ADO recordsets and connection objects should be explicitly closed. The same is true, even more so for the .Net framework's datareader and connection objects. For
instance, it is not possible to (re)use another datareader on the connection without closing the first. The result is an exception raised/run time
error.

--
Peter O'Reilly

[Peter O'Reilly]

> Hit it couple times then go to Enterprise Managment Managment/Current

Activity/Process Info and you will see only one connection.
So it's not necessary to close connection in an APS page. ADO closes it for you as soon as object goes out of scope.
Perhaps it's because you had to 2 Management consoles open - one for each
connection connection. A couple of times, I see that's definitive and
conclusive.

Reread my message. What did I write about SQL Server? What did I write
about load?
MSDN is wirtten by people and usually not by developers who actually created ADO.

I sure hope their writing is done by people(and not trolls, like here).
Some may jibe that their marketing department writes them, but they are
written by their technical staff many of them (software engineers) who have
coded their various products including ADO.

--
Peter O'Reilly

[Kevin Spencer]

Ah, yes. That's exactly right, George. :)

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

"George Ter-Saakov" <no****@hotmail.com> wrote in message
news:ua**************@TK2MSFTNGP12.phx.gbl...

I am talking about ASP. Not ASP.NET.
In ASP.NET connection must be closed.
In ASP it's not necessary.

George.
"Kevin Spencer" <ks******@takempis.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

And there is not need to close connections or destroy objects.

Hang on a second, George. Connections DO need to be closed, or disposed.
Setting objects to Nothing does Nothing. Closing Connections frees them up for re-use.

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

"George Ter-Saakov" <no****@hotmail.com> wrote in message
news:eq**************@TK2MSFTNGP11.phx.gbl...

I was talking about ASP (not ASP.NET)
In ASP objects are released when they go out of scope.

And there is not need to close connections or destroy objects.

There was a bug though in earlier versions of ADO when due to the cyclic reference between recordset and connection the connection will not be

closed

even if it goes out of scope.

George.
"Curt_C [MVP]" <software_AT_darkfalz.com> wrote in message
news:uk**************@TK2MSFTNGP12.phx.gbl...
> > In ASP.
> > Connection does not need to be closed,
> > Object does not need to be destroyed.
> >
> not true really.... they will eventually go away, but in the

meantime they

> can, and will, eat major resources. It's always better to explicitly
> close/kill them.
>
> > Also i bet that his ASP forms do not have any validations.
> >
> some of the ASP.NET ones are clientside though, and could be

replicated

in

> ASP.
>
>
> --
> Curt Christianson
> Owner/Lead Developer, DF-Software
> www.Darkfalz.com
>
>

[Andrea Williams]

ASP Best practices for our company say to "close the connections". We have
seen problems when connection are not explicitly closed, and that IS with
SQL Server. If connections aren't closed, OLEDB starts to return an
unspecified error after a while (depending on load) and the only way to get
rid of it is to reboot or change the conncetion string to ODBC. We found
the problem when converting to OLEDB from ODBC a while ago. ODBC doesn't
seem to care, but OLEDB does.

Andrea

"George Ter-Saakov" <no****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Yes. Do the test. I tested with MS SQL.
Create an ASP page (not asp.net)

<%
Dim con
Set con = CreateObject("ADODB.Connection")
con.Open "Provider=SQLOLEDB.1;Password=test;Persist Security Info=True;User ID=test;Initial Catalog=test;Data Source=test"
%>

Hit it couple times then go to Enterprise Managment Managment/Current
Activity/Process Info and you will see only one connection.
So it's not necessary to close connection in an APS page. ADO closes it for you as soon as object goes out of scope.
MSDN is wirtten by people and usually not by developers who actually created ADO.

BTW: It's practically impossible to write a clean ASP page which will close connections in any case (exception, script timeout, ...)
George.
"Peter O'Reilly" <Pe***********@timeinc.com!N!O!.S!P!AM!> wrote in message
news:ej**************@TK2MSFTNGP10.phx.gbl...

There was a bug though in earlier versions of ADO when due to the cyclic reference between recordset and connection the connection will not be

closed

even if it goes out of scope.

It was never a bug. In theory what you write should be the case (and is

ok

for a very light load), but practice tells me otherwise. Some RDBMS like Oracle 8,9i or MS Access (Jet) are much less forgiving than SQL Server

with

respect to not closing connections and recordsets. I have found this to

be

the case with IIS 4, 5, 5.1. Load testing a classic ASP application will make this immediately apparent.

Microsoft/MSDN docs have consistently parroted all along that ADO

recordsets

and connection objects should be explicitly closed. The same is true,

even

more so for the .Net framework's datareader and connection objects. For
instance, it is not possible to (re)use another datareader on the

connection

without closing the first. The result is an exception raised/run time
error.

--
Peter O'Reilly