TR Forums

steelcity_ballin · Fri May 20, 2005 9:56 am

Yet another oddity... And im sorry for awakening this forum with all my questions, they are all sorta related but all on different projects....

Okay, I have a recordset that selects a name based on something else, say what city you live in for example. If you're in "PA" it will return PETE ROTH.

Good. Now that works, simple. Now say I want to insert "PETE ROTH" or rather, the recordset.field.item("FIRSTNAME").value portion of that and throw it into a session variable for use. How would I go about this?

I get the "Either BOF or EOF, or the recordset no longer exists" error when I try to put a record set into a session variable for use. Basically, What it's for is based on a previous pages answers it generates an email with your name, obviously it needs your email to send it to, and some other general information that tailors an email customized for you.

Thing is, it cant ASK you the email address on the previous page, it looks up your name in a data base and cross references some other stuff and gets your email address. Now i am ONE HUNDRED % POSITIVE its getting the email address correctly via response.write blah blah However I need my email scrip i wrote to be something like

theEmailADdresTo = recordset1.field.item("yourEmail").value

But it throws a fit, how can I insert the email address from a recordset into my vbscript? It just throws up when i do it!

Sorry for another long one, these minor quirks are driving me nuts!

Darkmage · Mon Jun 27, 2005 3:28 pm

How many pages are involved here? For example, are you loading the email address via the recordset on page 3 of a 5-page process? Are you storing it in the session variable immediately, or are you trying to pass the recordset along to the next page?

How are you preparing your session variable?

UberGerbil · Mon Jun 27, 2005 4:06 pm

I don't entirely follow what you're trying to do, but you shouldn't need to put the whole recordset object into the session variable if all you need is the string containing the email. It sounds like the problem isn't your database lookup, it is dealing with the session variable. Can you post the code for that? And is this ASP, ASP.NET, or what?

steelcity_ballin · Mon Jun 27, 2005 4:30 pm

I solved my problems a long while back, it was correct he entire time. I was testing the page without the proper session variables invoked... that is I was testing just that page and it was having a fit because the session is set on the previous page.

Im an ass

Best part is AFTER I get all this up and running, my boss tells me she doesn't want it anymore. DAMNIT :evil:

Sparrow · Mon Jun 27, 2005 5:50 pm

pete_roth wrote:
Best part is AFTER I get all this up and running, my boss tells me she doesn't want it anymore. DAMNIT

ain't that always the way!

Darkmage · Mon Jun 27, 2005 9:00 pm

pete_roth wrote:
Best part is AFTER I get all this up and running, my boss tells me she doesn't want it anymore. DAMNIT

Heh. Been there, done that. I once spent four days building a module to fulfill a request for the client on the basis of "We're re-negotiating the contract, just get to work on these for we need them yesterday." Wouldn't you know it, during the negotiations on what could and could not be done on schedule, the part I had just finished was struck from the requirements. :roll:

steelcity_ballin · Tue Jul 26, 2005 2:41 pm

Didn't think starting a new thread was neccessary, as this sorta falls under the same general idea of recordset and Sql. So I have:

companies.Source = "SELECT * FROM Calls,Subject WHERE Calls.Subject = Subject.SubjectID AND CompanyName = '" + Request.Form("CompanyName") + "' ORDER BY CallID ASC"

Which basically displays results based on company name then what I WANT it to do, is take all the values of calls.subject, and set them equal to Subject.SubjectID. Calls. I did something on another page that works just fine but its NOT a complex WHERE clause, it works just as I expect it to. The code there is:

calls.Source = "SELECT CallDate, CallID, CallLength, CallTime, CompanyName, Subject.Subject,reason,notes,technician,incomingcall,contact FROM Calls, Subject WHERE Calls.Subject = Subject.SubjectID"

And this does exactly what I want my other (the one above this) to do, except that in this case, my WHERE clause has only one condition, and in my first it has two, namely to display the results based on company name AND set the calls.subject = subject.subjectID. Any ideas where im goofing? I'm still a n00b to sql.

steelcity_ballin · Tue Jul 26, 2005 2:51 pm

companies.Source = "SELECT CallDate, CallID, CallLength, CallTime, CompanyName, Subject.Subject,reason,notes,technician,incomingcall,contact FROM Calls, Subject WHERE Calls.Subject = Subject.SubjectID AND CompanyName = '" + Replace(companies__MMColParam, "'", "''") + "' ORDER BY CallID ASC"

that's the ticket. Ugly and inefficient yes, but Im doing something stupid in my select or Where clause, typing it all out works, so here here! haha

UberGerbil · Tue Jul 26, 2005 2:59 pm

BTW, if you are allowing people to type in the company name on your form (rather than picking from a list) you're open to a SQL injection attack.

steelcity_ballin · Tue Jul 26, 2005 3:02 pm

UberGerbil wrote:
BTW, if you are allowing people to type in the company name on your form (rather than picking from a list) you're open to a SQL injection attack.

Nope, gotta select from a list. But thanks! i'll keep that in mind, this thing is local only on our server, which has no connection to the internet, and is used to track support clals we recieve. Its crude atm but im constanttly refining it as I learn more.

Sparrow · Tue Jul 26, 2005 5:34 pm

pete_roth wrote:
UberGerbil wrote:
BTW, if you are allowing people to type in the company name on your form (rather than picking from a list) you're open to a SQL injection attack.

Nope, gotta select from a list. But thanks! i'll keep that in mind, this thing is local only on our server, which has no connection to the internet, and is used to track support clals we recieve. Its crude atm but im constanttly refining it as I learn more.

It's actually worse than that. A determined person could simply generate their own POST request and fill in whatever company name they like, since you're referencing the Form data directly.

I know that in PHP, Perl, etc., there is a simple way around this that involves using "parameterized" SQL. Here's a pseudo-code example:

sql = "UPDATE Companies SET CompanyName = ? WHERE ID = ?;"
Database.Execute(sql, sCompanyName, iCompanyID)

The ?'s in the SQL get automatically filled in using the parameters specified in the execute. It handles all the fudging of quote marks to make sure that nobody can hack your code. I actually prefer the way it looks in my code as well (looks cleaner to me, not so haphazard), but that's a personal preference.

ADO has a similar feature, which I'm going to look up right now.

steelcity_ballin · Tue Jul 26, 2005 5:38 pm

Sparrow wrote:
pete_roth wrote:
UberGerbil wrote:
BTW, if you are allowing people to type in the company name on your form (rather than picking from a list) you're open to a SQL injection attack.

Nope, gotta select from a list. But thanks! i'll keep that in mind, this thing is local only on our server, which has no connection to the internet, and is used to track support clals we recieve. Its crude atm but im constanttly refining it as I learn more.

It's actually worse than that. A determined person could simply generate their own POST request and fill in whatever company name they like, since you're referencing the Form data directly.

I know that in PHP, Perl, etc., there is a simple way around this that involves using "parameterized" SQL. Here's a pseudo-code example:
Code: Select all
sql = "UPDATE Companies SET CompanyName = ? WHERE ID = ?;"
Database.Execute(sql, sCompanyName, iCompanyID)
The ?'s in the SQL get automatically filled in using the parameters specified in the execute. It handles all the fudging of quote marks to make sure that nobody can hack your code. I actually prefer the way it looks in my code as well (looks cleaner to me, not so haphazard), but that's a personal preference.

ADO has a similar feature, which I'm going to look up right now.

Good to know, but im just going to leave it as it for now, I totally understand the concerns, but 3 people have access to this thing, im one of them. You have to be sitting in my chair during office hours too, so not being on the net helps haha! but for future reference in designing things of this nature I'll def. keep this in mind.

UberGerbil · Tue Jul 26, 2005 5:39 pm

Well, more than just entering "whatever company name they like" they could enter something like:
whatever'; DELETE * FROM Calls;

ADO supports parameterized queries, but ideally you'd be using a parameterized stored procedure in any case.

steelcity_ballin · Tue Jul 26, 2005 5:45 pm

UberGerbil wrote:
Well, more than just entering "whatever company name they like" they could enter something like:
whatever'; DELETE * FROM Calls;

ADO supports parameterized queries, but ideally you'd be using a parameterized stored procedure in any case.

They enter a company selection from a drop down list, as well as just about everything else on the site. And the boxes have character limits on them, the database itself will reject the entry afer X amount of characters.

Sparrow · Tue Jul 26, 2005 6:01 pm

I didn't really think you needed to change what you have. Nobody in your company (unless they're some kind of secret agent engaging in corporate espionage

) is going to try to hack you.

I'm just trying to highlight one of the more important security concerns for any database application on the web. And trying to point you in a good direction.

Beyond security, parameterized queries have another benefit: you never have to worry about getting your quote marks perfect -- it does that for you. And like I said, I think the code looks better too!

Sparrow · Tue Jul 26, 2005 6:07 pm

UberGerbil wrote:
Well, more than just entering "whatever company name they like" they could enter something like:
whatever'; DELETE * FROM Calls;

That's what I meant. I see now that the way phrased it didn't come out quite right.

TR Forums

Recordsets, session variables...

Recordsets, session variables...

Who is online