To combine or leave as is...

[David P. Jessup]

My current application I am working on consists of 3 separate ASP pages.
I'm posting data to each other page and using request.form to retrieve.

My first page has about 300 lines of code, the second has about 550 lines
and the last has about 300.

I feel comfortable making one page and making the 3 separate pages Subs to
call to. I'm just wondering about performance on a single page that will
have over 1000 lines of code. Each of the 3 pages do make ADO calls of some
sort. The first and last page make FSO calls too.

Any thoughts?

--
Thanks from this ASP Newbie

[Ray at]

I personally prefer having separate pages instead of trying to cram things
all into one page because they seem to have similarities. If they use the
same code at all, I'll throw it in an include, like:

fso.inc:
<object runat="server" progid="scripting.filesystemobject"
id="oFSO"></object>

data.inc:
<%
Dim oADO
Sub OpenData()
Set oADO = Server.CreateObject("ADODB.Connection")
oADO.Open "the connection string"
'''and for some damn reason on one of my servers, I suddenly have to do
this even though I'm defining the database in my connection string!
oADO.Execute "USE [SomeDB]"
End Sub

Sub CloseData()
oADO.Close
Set oADO = Nothing
End Sub
%>


So, if I know I'm going to need an FSO or my ADO connection, I just include
the appropriate file in that page. I try to make each page only have code
that is unique to that page, as much as possible.

And I don't necessarly use the .inc extension. We don't have to go off on
that tangent. :] That's just for illustration purposes.

Ray at work






"David P. Jessup" <davidATimntDASHtechDOTcom> wrote in message
news:u$71ugMlDHA.1004@TK2MSFTNGP09.phx.gbl...

> My current application I am working on consists of 3 separate ASP pages.
> I'm posting data to each other page and using request.form to retrieve.
>
> My first page has about 300 lines of code, the second has about 550 lines
> and the last has about 300.
>
> I feel comfortable making one page and making the 3 separate pages Subs to
> call to. I'm just wondering about performance on a single page that will
> have over 1000 lines of code. Each of the 3 pages do make ADO calls of

some

> sort. The first and last page make FSO calls too.
>
> Any thoughts?
>
> --
> Thanks from this ASP Newbie
>
>

[Tom B]

Slightly changing the subject, but my data.inc has a function called
ExecuteSQL like so.....

Function ExecuteSQL(sSQL)
Dim CN
Dim RS
Set CN=CreateObject("ADODB.Connection")
CN.Open "the usual"
Set RS=CreateObject("ADODB.Recordset")
RS.CursorLocation=3 'adUseClient
RS.Open sSQL, CN
Set RS.ActiveConnection=nothing
Set ExecuteSQL=RS
Set RS=nothing
CN.Close
End Function

Now, I don't have to open and close connections, I just do it all in this
one function.

On my pages I just execute sql statements against my function. If it's an
Update, Delete or Insert then I just ignore anything returned.



"Ray at <%=sLocation%>" <myfirstname at lane34 dot com> wrote in message
news:O$WOzlMlDHA.2424@TK2MSFTNGP10.phx.gbl...

> I personally prefer having separate pages instead of trying to cram things
> all into one page because they seem to have similarities. If they use the
> same code at all, I'll throw it in an include, like:
>
> fso.inc:
> <object runat="server" progid="scripting.filesystemobject"
> id="oFSO"></object>
>
> data.inc:
> <%
> Dim oADO
> Sub OpenData()
> Set oADO = Server.CreateObject("ADODB.Connection")
> oADO.Open "the connection string"
> '''and for some damn reason on one of my servers, I suddenly have to

do

> this even though I'm defining the database in my connection string!
> oADO.Execute "USE [SomeDB]"
> End Sub
>
> Sub CloseData()
> oADO.Close
> Set oADO = Nothing
> End Sub
> %>
>
>
> So, if I know I'm going to need an FSO or my ADO connection, I just

include

> the appropriate file in that page. I try to make each page only have code
> that is unique to that page, as much as possible.
>
> And I don't necessarly use the .inc extension. We don't have to go off on
> that tangent. :] That's just for illustration purposes.
>
> Ray at work
>
>
>
>
>
>
> "David P. Jessup" <davidATimntDASHtechDOTcom> wrote in message
> news:u$71ugMlDHA.1004@TK2MSFTNGP09.phx.gbl...

> > My current application I am working on consists of 3 separate ASP pages.
> > I'm posting data to each other page and using request.form to retrieve.
> >
> > My first page has about 300 lines of code, the second has about 550

lines

> > and the last has about 300.
> >
> > I feel comfortable making one page and making the 3 separate pages Subs

to

> > call to. I'm just wondering about performance on a single page that

will

> > have over 1000 lines of code. Each of the 3 pages do make ADO calls of

> some

> > sort. The first and last page make FSO calls too.
> >
> > Any thoughts?
> >
> > --
> > Thanks from this ASP Newbie
> >
> >

>
>

[Ray at]

That's a good idea. I can see myself using that for updates, inserts, and
deletes.

I've used functions like this before, but I don't think I've ever
genericized it. I should probably do that.

Function ReturnCategories()
Set o = server.CreateObject("adodb.connection")
o.open "connection"
Set rs = o.Execute("select catID,categories from theTable order by
Something")
If Not rs.EOF Then ReturnCategories = rs.GetRows()
rs.Close : Set rs = Nothing
o.Close : Set rs = Nothing
End Function

Then I can do like:

<select>
<%
aCats = ReturnCategories()
If Not IsEmpty(aCats) Then
For i = o To ubound(aCats, 2)
%>
<option value="<%=aCats(0, i)%>"><%=aCats(1, i)%></option>
<% Next %>
</select>


Ray at work


"Tom B" <shuckle@hotmail.com> wrote in message
news:uf%233BBNlDHA.2456@TK2MSFTNGP09.phx.gbl...

> Slightly changing the subject, but my data.inc has a function called
> ExecuteSQL like so.....
>
> Function ExecuteSQL(sSQL)
> Dim CN
> Dim RS
> Set CN=CreateObject("ADODB.Connection")
> CN.Open "the usual"
> Set RS=CreateObject("ADODB.Recordset")
> RS.CursorLocation=3 'adUseClient
> RS.Open sSQL, CN
> Set RS.ActiveConnection=nothing
> Set ExecuteSQL=RS
> Set RS=nothing
> CN.Close
> End Function
>
> Now, I don't have to open and close connections, I just do it all in this
> one function.
>
> On my pages I just execute sql statements against my function. If it's an
> Update, Delete or Insert then I just ignore anything returned.
>
>
>

[Tom B]

Yes, that's even better.

"Ray at <%=sLocation%>" <myfirstname at lane34 dot com> wrote in message
news:OnFhhcNlDHA.3316@tk2msftngp13.phx.gbl...

> That's a good idea. I can see myself using that for updates, inserts, and
> deletes.
>
> I've used functions like this before, but I don't think I've ever
> genericized it. I should probably do that.
>
> Function ReturnCategories()
> Set o = server.CreateObject("adodb.connection")
> o.open "connection"
> Set rs = o.Execute("select catID,categories from theTable order by
> Something")
> If Not rs.EOF Then ReturnCategories = rs.GetRows()
> rs.Close : Set rs = Nothing
> o.Close : Set rs = Nothing
> End Function
>
> Then I can do like:
>
> <select>
> <%
> aCats = ReturnCategories()
> If Not IsEmpty(aCats) Then
> For i = o To ubound(aCats, 2)
> %>
> <option value="<%=aCats(0, i)%>"><%=aCats(1, i)%></option>
> <% Next %>
> </select>
>
>
> Ray at work
>
>
> "Tom B" <shuckle@hotmail.com> wrote in message
> news:uf%233BBNlDHA.2456@TK2MSFTNGP09.phx.gbl...

> > Slightly changing the subject, but my data.inc has a function called
> > ExecuteSQL like so.....
> >
> > Function ExecuteSQL(sSQL)
> > Dim CN
> > Dim RS
> > Set CN=CreateObject("ADODB.Connection")
> > CN.Open "the usual"
> > Set RS=CreateObject("ADODB.Recordset")
> > RS.CursorLocation=3 'adUseClient
> > RS.Open sSQL, CN
> > Set RS.ActiveConnection=nothing
> > Set ExecuteSQL=RS
> > Set RS=nothing
> > CN.Close
> > End Function
> >
> > Now, I don't have to open and close connections, I just do it all in

this

> > one function.
> >
> > On my pages I just execute sql statements against my function. If it's

an

> > Update, Delete or Insert then I just ignore anything returned.
> >
> >
> >

>
>

[Tom B]

Why not selects?
It returns a disconnected recordset.

"Ray at <%=sLocation%>" <myfirstname at lane34 dot com> wrote in message
news:OnFhhcNlDHA.3316@tk2msftngp13.phx.gbl...

> That's a good idea. I can see myself using that for updates, inserts, and
> deletes.
>
> I've used functions like this before, but I don't think I've ever
> genericized it. I should probably do that.
>
> Function ReturnCategories()
> Set o = server.CreateObject("adodb.connection")
> o.open "connection"
> Set rs = o.Execute("select catID,categories from theTable order by
> Something")
> If Not rs.EOF Then ReturnCategories = rs.GetRows()
> rs.Close : Set rs = Nothing
> o.Close : Set rs = Nothing
> End Function
>
> Then I can do like:
>
> <select>
> <%
> aCats = ReturnCategories()
> If Not IsEmpty(aCats) Then
> For i = o To ubound(aCats, 2)
> %>
> <option value="<%=aCats(0, i)%>"><%=aCats(1, i)%></option>
> <% Next %>
> </select>
>
>
> Ray at work
>
>
> "Tom B" <shuckle@hotmail.com> wrote in message
> news:uf%233BBNlDHA.2456@TK2MSFTNGP09.phx.gbl...

> > Slightly changing the subject, but my data.inc has a function called
> > ExecuteSQL like so.....
> >
> > Function ExecuteSQL(sSQL)
> > Dim CN
> > Dim RS
> > Set CN=CreateObject("ADODB.Connection")
> > CN.Open "the usual"
> > Set RS=CreateObject("ADODB.Recordset")
> > RS.CursorLocation=3 'adUseClient
> > RS.Open sSQL, CN
> > Set RS.ActiveConnection=nothing
> > Set ExecuteSQL=RS
> > Set RS=nothing
> > CN.Close
> > End Function
> >
> > Now, I don't have to open and close connections, I just do it all in

this

> > one function.
> >
> > On my pages I just execute sql statements against my function. If it's

an

> > Update, Delete or Insert then I just ignore anything returned.
> >
> >
> >

>
>

[Ray at]

What do you mean, "why not selects?" I guess I could do the disconnected
recordset instead, but I never thought to. I'm going to ~guess~ that an
array will use a few fewer bytes of memory, but I don't know that for a
fact.

Ray at work

"Tom B" <shuckle@hotmail.com> wrote in message
news:OGlCvwNlDHA.2676@TK2MSFTNGP11.phx.gbl...

> Why not selects?
> It returns a disconnected recordset.
>
> "Ray at <%=sLocation%>" <myfirstname at lane34 dot com> wrote in message
> news:OnFhhcNlDHA.3316@tk2msftngp13.phx.gbl...

> > That's a good idea. I can see myself using that for updates, inserts,

and

> > deletes.
> >
> > I've used functions like this before, but I don't think I've ever
> > genericized it. I should probably do that.
> >
> > Function ReturnCategories()
> > Set o = server.CreateObject("adodb.connection")
> > o.open "connection"
> > Set rs = o.Execute("select catID,categories from theTable order by
> > Something")
> > If Not rs.EOF Then ReturnCategories = rs.GetRows()
> > rs.Close : Set rs = Nothing
> > o.Close : Set rs = Nothing
> > End Function
> >
> > Then I can do like:
> >
> > <select>
> > <%
> > aCats = ReturnCategories()
> > If Not IsEmpty(aCats) Then
> > For i = o To ubound(aCats, 2)
> > %>
> > <option value="<%=aCats(0, i)%>"><%=aCats(1, i)%></option>
> > <% Next %>
> > </select>
> >
> >
> > Ray at work

[Tom B]

You said, you could see yourself "using that for updates, inserts, and
deletes"
why not SELECTs?

But you are right, the array is probably a better way.


"Ray at <%=sLocation%>" <myfirstname at lane34 dot com> wrote in message
news:ebVDM4NlDHA.3024@tk2msftngp13.phx.gbl...

> What do you mean, "why not selects?" I guess I could do the disconnected
> recordset instead, but I never thought to. I'm going to ~guess~ that an
> array will use a few fewer bytes of memory, but I don't know that for a
> fact.
>
> Ray at work
>
> "Tom B" <shuckle@hotmail.com> wrote in message
> news:OGlCvwNlDHA.2676@TK2MSFTNGP11.phx.gbl...

> > Why not selects?
> > It returns a disconnected recordset.
> >
> > "Ray at <%=sLocation%>" <myfirstname at lane34 dot com> wrote in message
> > news:OnFhhcNlDHA.3316@tk2msftngp13.phx.gbl...

> > > That's a good idea. I can see myself using that for updates, inserts,

> and

> > > deletes.
> > >
> > > I've used functions like this before, but I don't think I've ever
> > > genericized it. I should probably do that.
> > >
> > > Function ReturnCategories()
> > > Set o = server.CreateObject("adodb.connection")
> > > o.open "connection"
> > > Set rs = o.Execute("select catID,categories from theTable order by
> > > Something")
> > > If Not rs.EOF Then ReturnCategories = rs.GetRows()
> > > rs.Close : Set rs = Nothing
> > > o.Close : Set rs = Nothing
> > > End Function
> > >
> > > Then I can do like:
> > >
> > > <select>
> > > <%
> > > aCats = ReturnCategories()
> > > If Not IsEmpty(aCats) Then
> > > For i = o To ubound(aCats, 2)
> > > %>
> > > <option value="<%=aCats(0, i)%>"><%=aCats(1, i)%></option>
> > > <% Next %>
> > > </select>
> > >
> > >
> > > Ray at work

>
>

[Ray at]

Oh, oh, I see. I meant using a generic SUB for executing updates, inserts,
and deletes. Like, things that I do not want a recordset returned from.
And then use a function to return arrays of data for SELECTS. Of course, I
can't even rememeber the last time I actually even coded an ASP page, so by
the time I get around to doing this, the Internet won't exist anymore.

Ray at work

"Tom B" <shuckle@hotmail.com> wrote in message
news:uxP4l9NlDHA.1948@TK2MSFTNGP12.phx.gbl...

> You said, you could see yourself "using that for updates, inserts, and
> deletes"
> why not SELECTs?
>
> But you are right, the array is probably a better way.

[David P. Jessup]

ACK....

Has my thread been hijacked? =)

--
Thanks from this ASP Newbie

[Ray at]

Yes. Get your own thread! :P

Ray at work

"David P. Jessup" <davidATimntDASHtechDOTcom> wrote in message
news:u7HlULOlDHA.3256@tk2msftngp13.phx.gbl...

> ACK....
>
> Has my thread been hijacked? =)
>
> --
> Thanks from this ASP Newbie
>
>

[Peter Foti]

"Ray at <%=sLocation%>" <myfirstname at lane34 dot com> wrote in message
news:O$WOzlMlDHA.2424@TK2MSFTNGP10.phx.gbl...

> I personally prefer having separate pages instead of trying to cram things
> all into one page because they seem to have similarities. If they use the
> same code at all, I'll throw it in an include, like:

<snip>

I agree. By cramming everything into one file, the only thing you
accomplish is to make your code bloated and hard to work on. I would keep
them separate (and use includes for common code).

Regards,
Peter Foti