|
| |
|
|
pd_it_guy
Posts: 94
Joined: 3/4/2008
Status: offline
 |
Just when I though I had this thing... - 3/21/2008 15:41:46
I will try to make this the last trip to the well... at least for today
On one page, I have a database results section that displays all the columns of any trouble ticket record that is in a just submitted mode. At the bottom of that page, there is another form with a couple of dropdown choices where the supervisor can enter the ticket number, assign someone to repair the item, update the status of the record, and hits submit. This form, with the updated fields gets kicked over to page 2, where we have a second database results section where we run an SQL UPDATE function to plug in the new values for the record to be updated. All that is OK as well.
Now where it all falls apart is at the botton of this second page I run a CDOSYS mail routine which is supposed to send a mail message to the lucky person of what they are supposed to fix, and all the details pertaining to it. That too runs OK but I can only recover the variables that I just POST'ed. What I need is to retrieve the original DB information displayed on the FIRST page IN ADDITION TO what the supervisors just added to update.
Looks like the SQL UPDATE function causes a bot to run through the entire record as it does its update function.
Are those variables getting kicked over from the first page along with the new info. Do I have to requery for them?
We tried the following but no luck and I have run out of guesses.
Request.Form("fieldname") is OK for what the supervisor just POST'ed but draws a blank for the original record.
FP("fieldname") doesnt work
FP_RS("fieldname") No
FP_FieldVal(fp_rs,"filedname") This is what is displayed by the bot for EVERY field
FP_SavedFields("filedname")
FP_RS(::fieldname::)
|
|
|
|
BeTheBall
Posts: 6336
Joined: 6/21/2002
From: West Point Utah USA
Status: offline
|
RE: Just when I though I had this thing... - 3/21/2008 16:04:29
Request.Form will capture all form fields submitted to the page. My guess is the other items are NOT part of the form being submitted. One easy work around is to add hidden fields to the form and populate those fields with the values from the database. So, within the form the supervisor fills out, include hidden fields such as:
<input type="hidden" name="fieldName" value="FP_FieldVal(fp_rs,"fieldname")">
Does that make sense?
_____________________________
Duane
Some people are like Slinkies . . . Not really good for anything . . . . . But they still bring a smile to your face when you push them down a flight of stairs.
| |
|
|
|
pd_it_guy
Posts: 94
Joined: 3/4/2008
Status: offline
|
RE: Just when I though I had this thing... - 3/21/2008 16:39:54
Thanks so much for the reply. It does make sense, and I have been trying to do just that for some time as it has become obvious that the needed data is NOT posting to the second page.
The problem is, that it does not seem to like the FP_FieldVal(fp_rs,"fieldname") syntax although it is exactly what the bot does only a few lines up to display the very same info I need. It gets an ASP error and seems to focus on the rs portion. I will try again exactly as you recommend but I have this feeling that there are a few more things going on here.
I will post back my results. Here's hoping...
| |
|
|
|
pd_it_guy
Posts: 94
Joined: 3/4/2008
Status: offline
|
RE: Just when I though I had this thing... - 3/21/2008 17:02:25
Gents:
This thing is determined to fight me to the bitter end.
It did not error out, that's good, but what got kicked over to page 2 where the mail is assembled was not the value of the field on the first page, but rather the literal string, thus: FP_FieldVal(fp_rs,"fieldname") and not what was in it. The reason for this is probably what you just said, that it has to be in a different place on page 1 to pick up the variable. However that poses a challenge as the sending form, while on the same page as the database results, follows the database results region.
So If I try to call a hidden input form element before the form section even starts would that be a problem.
If I try to initiate script <% .... that will save a variable beforehand, with the bot after my variable, it messes up the bot.
Can I call a variable without the script delimiters.
This is sooooo close.....
| |
|
|
|
pd_it_guy
Posts: 94
Joined: 3/4/2008
Status: offline
|
RE: Just when I though I had this thing... - 3/21/2008 17:23:56
Might I also add...
I just tried enclosing the database results section WITHIN the controlling form so I could perhaps pick up those variables, but that caused the form not to work anymore. So the controlling form it seems has to follow, and be separate from, the database results section. Also, calling the hidden field value exactly what the bot does, thus: value= <% FP_FieldVal(fp_rs,"filedname") %> caused it to crash.
So what has to happen, I guess, is that we try to somehow get the form values from the bot into a real variable while still in the gray section so I can request and package them later to send on.
Nothing comes easy.
| |
|
|
|
pd_it_guy
Posts: 94
Joined: 3/4/2008
Status: offline
|
RE: Just when I though I had this thing... - 3/21/2008 20:18:16
Success at last.
Once again you had it right. Right between the 'bots' I assigned variables, thus: <% fieldname=FP_FieldVal(fp_rs,"fieldname") %>. That locked them to the entire page.
And then recovered them in the posting form section hidden fields by the following: value=<% =fieldname %>
Posed just fine. Of course all of this just unearthed another rather frustrating problem which I shall describe in a separate post.
Thanks for your itme and interest.
| |
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
 Locked w/ New Messages |
 Locked w/o New Messages |
|
Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts
|
|
|
Printable Version 
k¥ 