Here's a tip sent in by Steve Sprague about data validation in ASP applications:
I've used a combination of two different validation methods in the past to solve the problem of displaying form data and errors back to the user. All datatype and field length checks are done using JavaScript. This
is quick and painless and saves a round-trip to the server. All other business rule checks are done in a COM object for performance reasons. The web site and the COM object must be running under MTS control for
this to work and the page must post back to itself.
First, I execute my "save" routine. This routine returns a disconnected recordset of errors. If the recordset is not empty, I know I have to display errors, and I need all of my user's form data back. To do this I get the current ASP "Request" object related to the MTS object context for my component. Then, I can snatch the original posted form data from the request object, pump it into a separate disconnected ADO recordset
and display it back to the user with all of my error messages.
Here's an example:
<%
Set marsErrors = moForm.SetData(CLng(mlFirmId), CStr(msFormType), _
CStr(msCallingAction), mlFormNbRet, _
mdtReqDtRet, mdtExpDtRet, _
miDaysGrRet, msRsnDndRet, _
msFinalFlag, mbIsSubsequent)
Call CheckError()
If marsErrors.EOF = False Then
mlErrorCount = marsErrors.RecordCount
marsErrors.Sort = "ENumber"
mbShowErrors = True
msAction = msCallingAction
Set marsFormData = moForm.GetPostedData()
Call CheckError()
End If
%>
The thing that makes this work nicely is my routine (not shown) to create
the page layout uses the same "marsFormData" recordset whether it is
coming from a new form, a form in edit mode, or a form in error status.