Results 1 to 3 of 3

Thread: Response object error in .asp

  1. #1

    Thread Starter
    Junior Member
    Join Date
    Nov 1999
    Location
    Forsyth, GA, USA
    Posts
    26
    In the first section, I see a typo using "ReRedirect".

    Also, to reference the field you need to use
    rsRedirect("urlfield") instead of "rsRedirect"(the recordset object). The default collection for the recordset is the fields collection but I don't think you can access the field using your syntax. The "Response.Redirect" does not use parenthesis.
    Brad
    Contract Developer

  2. #2
    New Member
    Join Date
    Aug 2000
    Posts
    4
    Brad,
    I found that typo (oops)and altered the other error and even changed the response redirect line to remove the parenthesis.
    36. thise = rsRedirect("urlfield")
    37 thise=Cstr(thise)
    43. Response.redirect thise

    I have some other error now.
    ADODB.Field error '800a0bcd'
    Either BOF or EOF is True, or the current record has been deleted. Requested operation requires a current record.
    /mydsn.com/www/redirect.asp, line 36
    which probably means I must've screwed up my connection string, or my parsing code, as a direct isql query gives the right results.

    Thanks for your sharp eyes.

  3. #3

    Thread Starter
    Junior Member
    Join Date
    Nov 1999
    Location
    Forsyth, GA, USA
    Posts
    26
    In regard to the EOF - BOF error:

    This would occur if the SQL query returned an empty recordset. It is ALWAYS prudent to check the status of the recordset object after a query that returns one. You can check rsRedirect.BOF and rsRedirect.EOF. This should be done before any attempt is made to access an expected resultset of a query that returns one. Otherwise you get an error or unexpected result.

    Checking the recordset(query) result before using it also lets you identify error conditions. If you are using "On Error Resume Next" you can create your own error handlers that are a lot more intuitive than the ADO/ASP errors. It also makes the code more "user friendly" and will appear more "professionally done". You can never have too much error trapping. Users do not accept fatal errors very well. Your support effort is also dramatically reduced.

    OK, I'm off the soap box.
    Brad
    Contract Developer

Posting Permissions

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



Click Here to Expand Forum to Full Width