View Full Version : How Many Pages does it take to maintain a database anyway?

08-01-2002, 06:06 PM

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.

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.

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!

08-01-2002, 06:27 PM
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)))

Roy Sinclair
08-01-2002, 07:43 PM
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.