Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 3 of 3
  1. #1
    Regular Coder
    Join Date
    Jun 2002
    Location
    Round Rock, Texas
    Posts
    443
    Thanks
    0
    Thanked 0 Times in 0 Posts

    How Many Pages does it take to maintain a database anyway?

    All;

    Background
    I've been assigned to modify an existing web application that maintains a database. The thing is using IIS, MS SQL Server 7, ASP, VBScript, Javascript. Target browser is IE 5.5 (we're an intranet, although the app was tested to work with NN (version?).

    The existing app uses two web pages for each logical data entity. One for "update" and another for "add". Thats six pages total! My immediate reaction when I first saw this was "what the...?". Naturally much of the code is essentially duplicated on each page. Fortunately much of the data validation code is in #include files.

    As I am new to web-based database programming, and web development (but NOT a novice programmer - whew!) I had to ask myself if there are some technical considerations for the code redundancy and apparent code maintenance faux pas.


    Question:
    Are there any reasons why I can't / shouldn't use the same web page for both updating existing data and adding new data records?

    What would the general (big picture) structure look like to implement a common data update page? I.E. what code or functions might be SQL, Server-side, Client-side? What are the control structures, and what do they look like, to handle the "are we working with existing or new records?" question.

    Discussion
    There must be some magic "complementary" code (SQL, ASP, script) that ties it all together. As our application stands now, I suspect it's kludgier than necessary - and redundant data update pages is the most obvious symptom I see.

    For example, does the code somehow need to know that it has to fetch an existing record vice not? Does the SQL->ASP->Client page "chain" fail if we try to fetch non existant records?

    Do we need the different pages because the client->ASP->SQL chain "fails" if the page doen't explictly know if it's handling a new vice existing record?

    I'm at the early stages of really grocking ASP but I know there are "update" and "addNew" methods to the recordset object.

    Seems to me the user gets to the page via an explicit "update" or "add" button (these buttons are on different pages in our app), so we can control the "back end" (do we fetch a record or not) and *still* display the data using the same page.

    Gawd! I want job security as much as the next fella, but doubling the development, testing, and maintenance load is a poor way to go about it. Excellent coding is the way!

  • #2
    Regular Coder
    Join Date
    Jun 2002
    Posts
    676
    Thanks
    1
    Thanked 0 Times in 0 Posts
    rad...
    for the database we have for conferences??? we have just a one® main page...where we click on one of the just a below® four links...

    edit exisiting conference...where you then have to give the 'record' number of the one you want to just a edit®...

    add just a new® one...just a selfexplanatory® :O)))


    just a delete® ...its similiar to the 'edit' in that you have to just a enter® the record you want to delete...

    view...where ya can just a view® alll the records :O)))
    The New JustaBuster Version 2.0 OR JustaBusta Lite V2.0
    ...just a special® thanx kinda hugs to jkd n' nex ...:O)))

    CommemorateWTC.com --Please lend your support

  • #3
    Senior Coder
    Join Date
    Jun 2002
    Location
    Wichita
    Posts
    3,880
    Thanks
    0
    Thanked 0 Times in 0 Posts
    For the pages I've developed, a single page handles both the Add new record as well as the update existing record. The usual arrangement is one page where the user can select an existing record to edit or has a way to note they want to add a new record.

    I simply pass a null key value to the add/edit page for an add while I pass the proper key value for the record to be edited.

    The add/edit page then reads up the record to be edited and displays it or empty/default values for an add. When submitted (which comes back to the add/edit page) the add/edit page detects the additional form fields and understands it's not another initial request so it then validates the data formats it into a call to the database stored procedure and performs the update/add. It should also be noted that the call to the stored procedure is identical for both the add and the edit. It's the stored procedure in the database which detects the difference and decides to update or insert accordingly.

    Some pages also offer a delete option which is similar to the add/edit, if the delete requires a review (Are you sure?) first then the add/edit page will handle that as well but if the delete doesn't require a review then the list page handles the delete request itself. We still use only one stored procedure though.
    Last edited by Roy Sinclair; 08-01-2002 at 06:46 PM.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •