Recordset vs. Form Field

Results 1 to 3 of 3

Thread: Recordset vs. Form Field

  1. #1
    Mitch Trope Guest

    Default Recordset vs. Form Field

    I am having a little debate with a colleague about the use of recordset fields versus form fields for display after a database is updated. I like to use the fields out of the recordset after the update as one last sanity check for the user, the programmer and anyone else involved as to the informaiton that was updated. He uses the fields right from the form. My contention is that if you just use the form field, all you see is the data you entered into the form and not what actually goes into the recordset. Does anyone have another good argument/counterargument? <BR>Are there any advantages/disadvantages to either approach in terms of speed, response time, client/server transfers, etc? Thanks in advance.<BR><BR>Sample difference in code:<BR>recordset.fields("field1") = request.form("data1")<BR>recordset.update<BR><BR>m ethod 1:<BR>Response.write "You added " & recordset.fields("data1")<BR><BR>method 2:<BR>Response.write "You added " & request.form("data1")

  2. #2
    Join Date
    Dec 1969

    Default Request.Form

    but only after you know that the update was successful...<BR><BR>Jason<BR>

  3. #3
    Join Date
    Dec 1969

    Default Best speed approach...

    is the form approach if the .Update doesn&#039;t generate an error and you are certain the update took place. The longer you keep an object (and in this case a connected object) alive, the worse off you are. Windows DNA says to release all objects and any applicable connections as soon as possible in order to free resources and return connections back to connection pool. <BR><BR>Are you using Access? If so, the connection pool arguement isn&#039;t relevant because Access doesn&#039;t support this. But the resource arguement is still valid.

Posting Permissions

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