Help with confirmation page (Full Version)

All Forums >> [Web Development] >> ASP and Database



Message

pd_it_guy -> Help with confirmation page (3/4/2008 21:48:08)

I think I posed this in the wrong forum before so here goes. I have a vehicle service database/website and part of that is an ASP page with a form, and when the form is complete I want to have it write to the Access database (so far so good) and also tell the admin that a service request arrived to go look. I have a simple CDOSYS mail routine in the ASP confirmation page that works fine, but it's static info, and of course I can pull out various parts of the form that was just posed to the confirmation page with the webbot bot S-field routine. What I cannot do is use the various form variables extracted by webbot bot make the email dynamic. Request.Form("form_field_name") just gives a blank. Trying to carve up the webbot bot script and make a variable out of it yields a "FALSE"???

Is there a way (on a confirmation page) to get those form variables to do something besides just show up in text.

Thank you all very much and I hope someone can set me on the right track.



Spooky -> RE: Help with confirmation page (3/5/2008 1:07:35)

Its best not to use a confirmation page for the email, you should use the CDO script in the same place as the database script, that way the variables are available to the email



pd_it_guy -> RE: Help with confirmation page (3/5/2008 10:57:56)

Rgr all that and thanks very much for the information... Let me look see if there is some good place to put that mail script on the initial form page. I dont want the mail to go out until the form is written, but perhaps there is a place it can go that won't execute until the form submit button is pushed.

I will work on this and let you all know of any success.



pd_it_guy -> RE: Help with confirmation page (3/5/2008 12:04:56)

We have made a promising start this morning. I put the CDO script just below the Access data base write script (before the first HTML tag). And it sent the mail OK. We think it was after the form got completed and sent, but we're not really sure.

Is that where it needs to go sequence wise, before the body, before the head, actually before the page?

The variables that get written to the access db are defined above. For a field called Operator do I call it by
Request.Form("operator")
Request("Operator")
Request(::Operator::)
<% =Operator %>
<% ::Operator:: %>

gotta be getting close to something here.




Spooky -> RE: Help with confirmation page (3/5/2008 13:41:21)

Can you show us the code from that page?



pd_it_guy -> RE: Help with confirmation page (3/6/2008 10:01:45)

Spooky,

I sure can. But before I do let me try a few other things first so I can better understand what it is and is not doing and will report back with the current code. I need to know if the CDOSYS mail script is firing off before the page is even being sent, or after, like we want. Because, we need some of the form variables to make up the mail. Right now it is above the first HTML tag (and below the Access write script) so you'd think it would be read sequentially, and go first.... but then again, maybe not. I am not sure placing it within the head or body would make a lot of difference.

Gimme a sec to try these variations out and I will let you know what happens.



pd_it_guy -> RE: Help with confirmation page (3/6/2008 10:08:18)

Ok it's now confirmed that where it is now runs as soon as the page opens. That may be useful for a notification that someone opened the page but not a lot of help otherwise. I'll move that script somewhere else.



pd_it_guy -> RE: Help with confirmation page (3/6/2008 10:42:57)

I moved it below the </FORM> tag and now can report that it does not execute until the form is sent. That is an improvement to be sure, as the user may abandon the form and no point sending something unless they commit to the submit operation. But... still no success in pulling already defined variables off the page. Mail sends just fine every time with static information. I am also pretty confident that the variables have been input, because by the time the mail script runs the user has set them all up and executes the database write.

We know these DON'T work results shown:

Request("Form_Variable") (comes up blank)
Request.Form("Form_Variable") (comes up blank)
Request(::Form_Variable::) (comes up blank)
Form_Variable (comes up blank)
<% =Form_Variable %> (generates script error)
<% ::Form_Variable:: &> (generates script error)

Any ideas out there to fetch a variable that already been defined, and exists on the same page?????



Spooky -> RE: Help with confirmation page (3/6/2008 13:49:41)

quote:

Ok it's now confirmed that where it is now runs as soon as the page opens.

This cant be the page that submits to the database?
I dont mean the FORM page that submits - I mean the page that processes the form submission?



pd_it_guy -> RE: Help with confirmation page (3/6/2008 13:52:08)

After going absolutely nowhere for the past few hours, I was fortunate to stumble across another thread and William Lee was able to set me right. The variables I needed to patch into my CDOSYS mail were really neither POSTED anywhere, nor were they GET-able. What we did was, fetch them as the confirmation field web bot did, but by using FP_ConfirmField("field_name") and FP_Saved_Fields("FieldName") we could make those fields into variables and turn them into the subject and message of the email. While all of this might have worked from the form page it was less cluttered to put the mail routine on the confirm page and that way if they decide not to submit, the routine won't try to run dry.

You guys are the best. Thanks so much.



pd_it_guy -> RE: Help with confirmation page (3/6/2008 14:01:29)

Spooky

I just saw your post.

The form exists on vehicle.asp and it is the form and on Submit it also posts to the access database. All one page. The confirm page vehicle.confirm.asp tells the submitter it went through, and from there, we sent the alert mail to the administrator that a car has broken down (and now he knows which car, where it is and what the problem was). And since we control the list of the sumbitters, and all submitters are employees we can parse that initial input into the "from" for the CDOSYS. Administrator looks at database for new tickets and assigns to corp yard, radio repair, IT, inhouse repair, etc. and on his submit THEY get the mail to come and fix and know what parts to bring. My first shot at using Access with FP front end, cheap, crude and effective.



Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.078125