ASP Coding Questions Discussion

Discussion in 'ASP General' started by Lin Ma, Aug 11, 2003.

  1. Lin Ma

    Lin Ma Guest

    Hi,

    I am wondering if I am doing right. Please advise.

    I create a system with 8 major steps and each step can go different
    direction. General speaking, a lot of if statements and functions inside.

    Each page is over 1000 lines. In order for me to debug, I separate the lines
    by function and create a template page.

    Then I use <--# include... --> to link to this template page.

    Also some of the code are shared with other page link query, table..., I
    also create a temp page for this and include into other pages.

    The pro is that:

    1. if update, I just update one temp page and all the page will be updated.
    2. easy to debug because it will make the page shorter. The one with include
    page has only 140 lines and without the include page is over 1500 lines.

    The con may be:

    1. too many include command to make the system slow??

    My question is Am I Doing correct? Or there is a better solution?

    Thanks,

    Lin Ma
     
    Lin Ma, Aug 11, 2003
    #1
    1. Advertising

  2. What kind of application needs 1000 lines per page?

    That seems ludicrously overboard, IMHO.





    > Each page is over 1000 lines. In order for me to debug, I separate the

    lines
    > by function and create a template page.
     
    Aaron Bertrand - MVP, Aug 11, 2003
    #2
    1. Advertising

  3. Lin Ma

    Lin Ma Guest

    Thanks for the response. I have tables, headers, queries, JavaScript, I also
    have if statements... Some pages also send email to certain group...

    The system is like a documentation approval system, different level people
    will take different action, sign their option and move to next level person.
    The next person can reject, accept, on hold... A lot of functions.

    My point is that Can I divide my code into server area by function. Each of
    the area creates a separate file. Then use Include command to assembly this
    files together?

    Thanks for the response.

    Lin



    "Aaron Bertrand - MVP" <> wrote in message
    news:%23$...
    > What kind of application needs 1000 lines per page?
    >
    > That seems ludicrously overboard, IMHO.
    >
    >
    >
    >
    >
    > > Each page is over 1000 lines. In order for me to debug, I separate the

    > lines
    > > by function and create a template page.

    >
    >
     
    Lin Ma, Aug 11, 2003
    #3
  4. Off course you can do it but, always remember that a SSI (include statement)
    is writen in the code is always included before any building of the code.
    this mean that if you include a file in an if ... end if statement this file
    will always be included.
    This is a bit heavy for the server but can be really helpful for a debuging
    purpose.
    do not overuse it, that's all
     
    Martin CLAVREUIL, Aug 11, 2003
    #4
  5. > My point is that Can I divide my code into server area by function. Each
    of
    > the area creates a separate file. Then use Include command to assembly

    this
    > files together?


    No, but you could use server.execute(). Includes are processed before ASP,
    so any logic you use in ASP to determine which files to include will be too
    late.
     
    Aaron Bertrand - MVP, Aug 11, 2003
    #5
  6. Lin Ma

    Lin Ma Guest

    Thanks.

    Is there a better way to do to make page shorter?

    Thanks a lot.

    Lin

    "Martin CLAVREUIL" <> wrote in message
    news:...
    > Off course you can do it but, always remember that a SSI (include

    statement)
    > is writen in the code is always included before any building of the code.
    > this mean that if you include a file in an if ... end if statement this

    file
    > will always be included.
    > This is a bit heavy for the server but can be really helpful for a

    debuging
    > purpose.
    > do not overuse it, that's all
    >
    >
     
    Lin Ma, Aug 11, 2003
    #6
  7. Lin Ma

    Jeff Cochran Guest

    On Mon, 11 Aug 2003 09:43:03 -0500, "Lin Ma" <> wrote:

    >I create a system with 8 major steps and each step can go different
    >direction. General speaking, a lot of if statements and functions inside.
    >
    >Each page is over 1000 lines. In order for me to debug, I separate the lines
    >by function and create a template page.


    Creating functions is smart if the same code is being executed
    multiple times. If executed once, just put it there.

    1,000 lines is big. Big enough that you're likely causing a slowdown
    somewhere that you don't need to. Modularize the options and put them
    in separate code pages.

    >Then I use <--# include... --> to link to this template page.


    In general, use includes to place the exact same block of code in
    multiple pages. If it only runs once for the page it's on, don't use
    an include.

    But, you *might* use an include to separate code from HTML.

    >Also some of the code are shared with other page link query, table..., I
    >also create a temp page for this and include into other pages.


    This is what includes are designed for, shared code or portions of
    pages. I don't see the reason for a temp page, but that may be your
    explanation or my ignorance that's confusing me.

    >1. if update, I just update one temp page and all the page will be updated.


    Welcome to the reason for includes.

    >2. easy to debug because it will make the page shorter. The one with include
    >page has only 140 lines and without the include page is over 1500 lines.


    Bleh! Break it into multiple pages. Just beacuse you can put
    everything on one page doesn't mean you should.

    >The con may be:
    >
    >1. too many include command to make the system slow??


    Maybe, probably not noticably considering the system is processing all
    those lines.

    >My question is Am I Doing correct? Or there is a better solution?


    No matter how you do it, there's *always* a better solution. :)

    I'd look at the programming logic. You mentioned eight major steps.
    How many minor steps, and how many of those can be broken into
    separate pages. Cheap example:

    Big Pages:
    ===================
    If User is Supervisor Then
    Do code
    Do more code
    Do more code
    End If

    If User is Employee Then
    Do code
    Do more code
    Do more code
    End If
    ====================

    Small Pages:
    ===================
    If User is Supervisor Then
    Goto Supervisor.asp
    End If

    If User is Employee Then
    Goto Employee.asp
    End If
    ====================

    In the separate ASP pages, do the code for that IF statement. In this
    pseudocode it saves four lines for the main page, and each individual
    page is easier to debug.

    Jeff
     
    Jeff Cochran, Aug 12, 2003
    #7
  8. In article <>, says...
    > My point is that Can I divide my code into server area by function.
    > ... Then use Include command to assembly this files together?


    Sure you can, Lin Ma. Here's an example for you:

    -----<begin file capitalizeWord.asp>-------
    <%
    Function capitalizeWord(w)
    dim s, t, u, l
    l = Len(w)

    if (l = 0) Then
    capitalizeWord = ""
    exit Function
    End If

    s = Left(w, 1)
    t = Right(w, l - 1)
    u = Ucase(s)

    capitalizeWord = u & t

    End Function
    %>
    -----<end file capitalizeWord.asp>-------

    and in file tests.asp:

    ------<begin file tests.asp>------
    <%@ Language=VBScript %>
    <%Option Explicit%>

    <!--#include virtual="bmlc_asp/includes/adovbs.inc"-->

    <!--#include virtual="bmlc_asp/includes/capitalizeWord.asp"-->
    <!--#include virtual="bmlc_asp/includes/ConnectionString.asp"-->

    <!--#include virtual="bmlc_asp/includes/debugScreen.asp"-->
    <!--#include virtual="bmlc_asp/includes/makeOption.asp"-->
    <!--#include virtual="bmlc_asp/includes/queryDatabase.asp"-->

    <!--#include virtual="bmlc_asp/TestCreation/TestClass.asp"-->
    <!--#include virtual="bmlc_asp/TestCreation/TestQuestionClass.asp"-->

    -------<end file .asp>-------

    Notice that you have to do the inclusions outside of the asp markers.
    Also, there is no built-in protection against redundant including of
    symbols, (no #ifdef in C++ speak) so you will have to come up with some
    kind of scheme to protect yourself against that.

    -- Rick
     
    Guinness Mann, Aug 12, 2003
    #8
  9. > I'm a little confused. I'm somewhat new to this ASP stuff, but I've
    > been developing software for over 20 years (way over, come to think of
    > it), and to my mind 1000 lines is not a big program.


    For a "real" application, no. For a web page, that's massive. I've been
    developing ASP applications for, what, 7 or 8 years now? IIS 3 beta 2,
    whenever that was made available. And I've never seen, much less written,
    an ASP page with 1000 lines.

    > Rather than have an unruly, unmanageable string of response.redirect-
    > related pages like the system it replaces, it has a central ASP page
    > that accepts the client-side input and generates the appropriate
    > response pages on the fly.


    And you think this is more efficient?

    > So are you (Aaron, specifically) claiming that I should break that up
    > into a dozen individual pages that use the WEB equivalent of "goto"
    > (response.redirect) to switch between them?


    When I build my sites, almost all of my content is stored in the database.
    The information is not always retrieved directly from the database, e.g.
    aspfaq.com uses a caching technology which only gets updated when the
    articles actually change. The entire aspfaq.com site is about 120 lines of
    code, and a good portion of that is style sheets / client-side javascript.

    However I'm not claiming at all what you should or should not do. I think
    if you have 1500-2000 lines of code, that's going to be a royal PITA to
    manage, no matter how you decide to break it up (or not at all). I just
    can't, for the life of me, imagine what you would need to do - for a set of
    web pages - that would require that much code.

    A
     
    Aaron Bertrand - MVP, Aug 12, 2003
    #9
  10. Lin Ma

    Jeff Cochran Guest

    >> >I create a system with 8 major steps and each step can go different
    >> >direction. General speaking, a lot of if statements and functions inside.
    >> >
    >> >Each page is over 1000 lines. In order for me to debug, I separate the lines
    >> >by function and create a template page.

    >>
    >> 1,000 lines is big. Big enough that you're likely causing a slowdown
    >> somewhere that you don't need to. Modularize the options and put them
    >> in separate code pages.

    >
    >I'm a little confused. I'm somewhat new to this ASP stuff, but I've
    >been developing software for over 20 years (way over, come to think of
    >it), and to my mind 1000 lines is not a big program. In fact, it's
    >barely non-trivial.


    VB apps routinely run many thousands of lines of code. But rarely
    does the server need to process an entire VB application just to
    display a logon screen. Plus, the nature of ASP and the web means you
    don't need all the code for an application in one page.

    >Is it a matter of terminology? When Lin Ma says "pages" maybe she
    >doesn't mean what you guys mean when you say pages.


    My take is a "page" means a single "file" processed and sent to the
    browser.

    >In one of the subsystems of my application I have a main "page" that has
    >about 450 lines in it. About half of that is the main code (about half
    >of which is comments) and the other half is utility subroutines. There
    >is no display code in this file.


    If Lin Ma has 1,000 lines and half are comments and another third are
    blank, that's a different story. But in the ASP world, 1,000 lines of
    code is pretty danged big.

    >In this main "page" I include fourteen directly related ASP files and
    >four data files. The ASP files collectively have about 700 lines in
    >them. In addition I include another nineteen general purpose ASP files
    >that do things like capitalize words, query the database, generate
    >dynamic "<select>" controls, etc. That adds another 500 lines of code,
    >or so.


    That can also be dramtically squeezed from the sounds of it. Or at
    least broken up.

    >Rather than have an unruly, unmanageable string of response.redirect-
    >related pages like the system it replaces, it has a central ASP page
    >that accepts the client-side input and generates the appropriate
    >response pages on the fly.


    Unruly and unmanageable aren't the code's fault. But the solution is
    rarely putting everything in one large file.

    >I don't see how it could be done in less than, well, 1500 - 2000 lines
    >of code.


    I don't either. But I don't have the code... :)

    >So are you (Aaron, specifically) claiming that I should break that up
    >into a dozen individual pages that use the WEB equivalent of "goto"
    >(response.redirect) to switch between them?


    No. But discreet points where user input is needed probably should be
    in discreet pages. You have 500 lines of code that query databases,
    capitalize words, create dynamic SELECT controls, all of which could
    possibly be better handled elsewhere. (Well, for one thing, ASP.NET
    might help with some of your controls...) If you don't need to query
    a database at the same time you capitalize words, don't put the
    functions in the same page. In fact, handle capitalization on the
    input side instead of the output, you capitalize once instead of every
    time.

    There's no real "method" to handle any of this. And what works in one
    case most certainly won't work in all. For example, I have pages
    which could easily be optimized, but they rarely get run and the
    performance increae would be minimal so why bother? My efforts are
    better spent elsewhere.

    Jeff
     
    Jeff Cochran, Aug 12, 2003
    #10
  11. In article <>,
    says...
    > When I build my sites, almost all of my content is stored in the database.
    > The information is not always retrieved directly from the database, e.g.
    > aspfaq.com uses a caching technology which only gets updated when the
    > articles actually change. The entire aspfaq.com site is about 120 lines of
    > code, and a good portion of that is style sheets / client-side javascript.


    I just had a look at your homepage, and one of the lines is 6,566 chars
    long. If I had 6,566 character-long-lines, I'd be able to complete my
    websites in well under 120 lines, too. :)


    In article <>,
    adds...
    > VB apps routinely run many thousands of lines of code. But rarely
    > does the server need to process an entire VB application just to
    > display a logon screen. Plus, the nature of ASP and the web means you
    > don't need all the code for an application in one page.


    Well, see, then it *is* a matter of terminology. I know that I don't
    use that much code to display the screens that I present to the user,
    and I suspect Lin Ma doesn't either. We're building large apps in ASP.
    Maybe that's a bad idea.

    I dunno. I suppose I could put all the business logic into activeX
    objects and just do the rendering in ASP, but when I started this
    project I didn't understand that. There would still be code to
    maintain, although I admit I could make much better code in C++ than in
    VBS...

    I have a program. It has branches. Depending on which branch you take,
    different code is included. There is code for students. Code for
    instructors. Code for monitors. Code for administrators. I'm not just
    serving up a bunch of static pages.

    If you sum the lines of code I mentioned (about 1650) and divide that
    figure by the number of files in the subsystem (34) you get less than 50
    lines/file. On average. And they're never all included at the same
    time. And about half (700) of those lines are re-used in other
    subsystems.


    Quoting Aaron again:
    > Rick said:
    >> Rather than have an unruly, unmanageable string of response.redirect-
    >> related pages like the system it replaces, it has a central ASP page
    >> that accepts the client-side input and generates the appropriate
    >> response pages on the fly.


    >And you think this is more efficient?


    Well...yeah. Efficient with respect to maintenance ... reliability ...
    ease of change ... in other words efficient with respect to all the
    things that make the difference between a software engineer and some kid
    with a dbase compiler. :)

    My favorite part about it is that all the logic about what to display is
    centralized where it can easily be reviewed or modified.

    ---

    Remember, Lin Ma's question was whether or not it is possible to take a
    large app and divide it up into modules of functionality and include
    them where needed, instead of having everything in one huge file. The
    answer is yes, most certainly.


    -- Rick
     
    Guinness Mann, Aug 12, 2003
    #11
  12. Lin Ma

    Bob Barrows Guest

    Guinness Mann wrote:
    > In article <>,
    > says...
    >> When I build my sites, almost all of my content is stored in the
    >> database. The information is not always retrieved directly from the
    >> database, e.g. aspfaq.com uses a caching technology which only gets
    >> updated when the articles actually change. The entire aspfaq.com
    >> site is about 120 lines of code, and a good portion of that is style
    >> sheets / client-side javascript.

    >
    > I just had a look at your homepage, and one of the lines is 6,566
    > chars long. If I had 6,566 character-long-lines, I'd be able to
    > complete my websites in well under 120 lines, too. :)
    >
    >

    :)
    Good one, but I think he's saying that the code used to generate those 6566
    characters is only 120 lines long. Remember: he said most of the content is
    stored in a database? I can well imagine that the code used to extract the
    content from the db is not that long ...

    Bob Barrows
     
    Bob Barrows, Aug 12, 2003
    #12
  13. In article <ePh$>,
    says...
    > Guinness Mann wrote:
    > > I just had a look at your homepage, and one of the lines is 6,566
    > > chars long. If I had 6,566 character-long-lines, I'd be able to
    > > complete my websites in well under 120 lines, too. :)
    > >
    > >

    > :)
    > Good one, but I think he's saying that the code used to generate those 6566
    > characters is only 120 lines long. Remember: he said most of the content is
    > stored in a database?


    But then how is his website relevent to a discussion of large
    applications? All he's doing is serving static pages. In concept it
    could be done in four or five lines... In practice, of course it takes
    a few more.

    But that's nothing like having to generate all of the content except
    formatting, dynamically.

    Speaking of formatting, am I the only person in the world who puts some
    effort into formatting my ASP code so that it looks good in "view
    source?"

    For instance, this is "view source" code: (I added the dots here on the
    newsgroup to keep the indentation from collapsing. They're actually
    rendered as tabs.)

    <!-- Begin Greetings.Asp -->
    <table style='border:none; width:100%'>
    .....<tr>
    .........<td align='left' class='greetings' style='width:25%;'>
    .............Spanish&nbsp;Language
    .........</td>
    .........<td align='center' class='greetings'>
    .............(If you're not&nbsp;John&nbsp;Adams, please&nbsp;
    .............<A HREF='/bmlc_asp/shell/getuser.asp'>click here</A>)
    .........</td>
    .........<td align='right' class='greetings' style='width:25%;'>
    .............Class ID #0000000000spa</td>
    .....</tr>
    </table>
    <!--End Greetings.asp-->

    Another cool thing I found out is that ASP code inside HTML comments
    will get executed on the server and written to the client, but NOT
    DISPLAYED. But they'll show up in the "view source."

    So, for instance, if you include:

    <!-- Called from <%=Request.ServerVariables("SCRIPT_NAME")%> -->

    in your source file, it will be rendered in view source like this:

    <!-- Called from /bmlc_asp/tests/testpresenter.asp -->

    but it won't be visible in the browser. It's a handy way to add
    debugging variables without screwing up your presentation.

    -- Rick
     
    Guinness Mann, Aug 13, 2003
    #13
  14. > Speaking of formatting, am I the only person in the world who puts some
    > effort into formatting my ASP code so that it looks good in "view
    > source?"


    Why go to the trouble? I render most of my HTML output from Response.Write
    calls. I have no use for the result of taking the effort to add all kinds
    of VBTab and VBCrLf constants to the code... bloating it, for what? HTML is
    not C++... if you have a problem with a table, it should be trivial to
    solve. If it isn't, your HTML is too complex...
     
    Aaron Bertrand [MVP], Aug 13, 2003
    #14
  15. > I just had a look at your homepage, and one of the lines is 6,566 chars
    > long. If I had 6,566 character-long-lines, I'd be able to complete my
    > websites in well under 120 lines, too. :)


    Uh, that's a stream of output from the database and inline functions, not a
    hard-coded line in ASP.

    > Well...yeah. Efficient with respect to maintenance ... reliability ...
    > ease of change ... in other words efficient with respect to all the
    > things that make the difference between a software engineer and some kid
    > with a dbase compiler. :)


    Why, because there are fewer pages? 1,500 lines of code is 1,500 lines of
    code. I guess if you're maintaining your code more often than running it...
    if you're having the ASP engine process 1,500 lines of code for every single
    page in your application, even the ones that only use 20 lines, the
    maintenance aspect does not override the performance impact, IMHO. And I
    still content that having one huge file does not necessarily make it easier
    to manage. Personally, I'd rather see them separated out by functionality,
    purpose, etc.
     
    Aaron Bertrand [MVP], Aug 13, 2003
    #15
  16. Lin Ma wrote:
    <snipped>
    > The con may be:
    > 1. too many include command to make the system slow??

    It won't be slow except on the *first* page request after the server
    starts. The reason is that the first time an ASP page is requested, it
    is compiled to bytecode and saved in IIS memory. On successive calls,
    the already-compiled bytecode is loaded. So only the first page request
    will be slow. For more details see
    http://groups.google.com/groups?q= ...&rnum=1&ic=1&selm=

    > My question is Am I Doing correct? Or there is a better solution?

    While the structure you use is not common among ASP developers, it does
    have some advantages and is perfectly fine, especially if it works for
    you. There is no reason to abandon a successful approach.

    FWIW the approach you use is sometimes called the "fusebox" approach. It
    is most commonly used in the scripting language/engine Cold Fusion. But
    it can be used in any language, as you can see.

    Good Luck,
    Michael D. Kersey
     
    Michael D. Kersey, Aug 13, 2003
    #16
  17. Lin Ma

    Bob Barrows Guest

    Guinness Mann wrote:
    > In article <ePh$>,
    > says...
    >
    > Speaking of formatting, am I the only person in the world who puts
    > some effort into formatting my ASP code so that it looks good in "view
    > source?"
    >

    I agree with Aaron. I really don't care what it looks like when I view
    source. I'm only viewing source for debugging purposes, which only happens
    during the application development phase, at most once or twice (yeah, right
    <grin>) - Any reformatting can be done by copying and pasting from notepad
    into my editor. Once that phase is done, I really don't mind forcing the
    hacker trying to reverse-engineer my page to add his own whitespace ...

    Bob Barrows
     
    Bob Barrows, Aug 13, 2003
    #17
  18. Lin Ma

    Jeff Cochran Guest

    >I dunno. I suppose I could put all the business logic into activeX
    >objects and just do the rendering in ASP, but when I started this
    >project I didn't understand that. There would still be code to
    >maintain, although I admit I could make much better code in C++ than in
    >VBS...


    That's an entirely different discussion, but it really does determine
    a great portion of your coding design. There's always a debate about
    where to place business logic, in a web app it's often on the web
    server, but it could be front-end in an ActiveX control, or back end
    in a database rule or stored procedure. Sometimes it makes sense to
    choose one over another, sometimes it's the programmer's experience
    that dictates the choice.

    >I have a program. It has branches. Depending on which branch you take,
    >different code is included. There is code for students. Code for
    >instructors. Code for monitors. Code for administrators. I'm not just
    >serving up a bunch of static pages.


    Nobody's talking about serving static pages, but rather about using
    multiple pages over cramming all the code into one.

    >If you sum the lines of code I mentioned (about 1650) and divide that
    >figure by the number of files in the subsystem (34) you get less than 50
    >lines/file. On average. And they're never all included at the same
    >time. And about half (700) of those lines are re-used in other
    >subsystems.


    That's different. On a dynamic include you can do this. The way Lin
    Ma had described the setup, all lines were included, and by that
    virtue processed, they were just broken into separate files for ease
    of debugging and maintenance. If you're using 30 files and including
    only those pertinent to the page being executed, whether dynamically
    or by manual design, that's normal good programming.

    The real problem with ASP is the difficulty of doing dynamic includes.
    It's easy to do "If this then do this" but not as easy to do "If this
    then do this, but if not, don't even put the code to do it in..."

    Jeff
     
    Jeff Cochran, Aug 13, 2003
    #18
  19. Lin Ma

    Ray at Guest

    "Guinness Mann" <> wrote in message
    > > Speaking of formatting, am I the only person in the world who puts some
    > > effort into formatting my ASP code so that it looks good in "view
    > > source?"


    No, you're not.



    > "Aaron Bertrand [MVP]" <> wrote
    > Why go to the trouble?


    I guess for the same reason I wash my car instead of leaving it dirty,
    although it runs the same regardless.
    > I render most of my HTML output from Response.Write
    > calls. I have no use for the result of taking the effort to add all kinds
    > of VBTab and VBCrLf constants to the code... bloating it, for what? HTML

    is
    > not C++... if you have a problem with a table, it should be trivial to
    > solve. If it isn't, your HTML is too complex...


    Aaron, you know that you can interlace your ASP code with HTML, right? ;P

    I don't disagree with you about the HTML, but I personally "code" all my
    HTML with strict tabbing, because when I do miss a tag somewhere or
    something, it'll jump right out on me. I'm not going to spend an hour
    looking for some stupid <tr> somewhere instead of doing what I really should
    be doing. That is why I "code" my HTML they I do.

    Ray at work
     
    Ray at, Aug 13, 2003
    #19
  20. Guinness Mann wrote:
    <snipped>
    > I dunno. I suppose I could put all the business logic into activeX
    > objects and just do the rendering in ASP, but when I started this
    > project I didn't understand that. There would still be code to
    > maintain, although I admit I could make much better code in C++ than in
    > VBS...

    In all likelihood that would prove to be slower performance-wise. It
    turns out that the additional time and memory required to load activeX
    objects and marshall data to/from them causes them to be slower in most
    instances.

    The upshot is that while, with a component the server is busy handling a
    CreateObject call and loading the component, a script would already be
    executing and doing useful work. So script can actually make better use
    of memory and CPU cycles, and usually outruns the component-based
    approach:

    "Rule of thumb: unless there are at least 100 lines of script and some
    big loops in that script, it's probably not worth thinking about
    translating that page into a component." Alex Homer, Dave Sussman,
    Brian Francis, page 1042, "Active Server Pages 3.0"
    (Wrox Press Ltd., 1999)

    The book goes on to describe in more detail the circumstances under
    which one should use components. Note the implication that any
    component-based architecture requires that you do some very heavy
    compute-bound work. This is not a common requirement.

    See Microsoft's own proof that this really occurs in Figure 9 of
    Microsoft's Nile.com benchmarks, which clearly shows how VBScript
    outruns VB COM components especially under heavy load(many users):
    http://msdn.microsoft.com/library/en-us/dnnile/html/docu2kbench.asp?frame=true

    Good Luck,
    Michael D. Kersey
     
    Michael D. Kersey, Aug 13, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. vasss_n
    Replies:
    1
    Views:
    965
    Krissy
    Aug 26, 2003
  2. William Gower
    Replies:
    1
    Views:
    331
  3. mazdotnet

    Discussion forum solution (ASP.NET)

    mazdotnet, Jun 14, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    385
    Winista
    Jun 14, 2006
  4. calmar
    Replies:
    11
    Views:
    916
    calmar
    Feb 21, 2006
  5. Bob Barrows

    Re: ASP Classic > ASP.net discussion

    Bob Barrows, Feb 8, 2012, in forum: ASP General
    Replies:
    0
    Views:
    1,260
    Bob Barrows
    Feb 8, 2012
Loading...

Share This Page