Insert data to myql problem

helo anybody help me solve this code below: hope u can help me plss



error:

Notice: Undefined index: mode in F:\server\htdocs\coupon\admin\mnagelist\listing.ph p on line 462

Notice: Undefined variable: coupon_url in F:\server\htdocs\coupon\admin\mnagelist\listing.ph p on line 472

Notice: Undefined variable: store_name in F:\server\htdocs\coupon\admin\mnagelist\listing.ph p on line 472

Notice: Undefined variable: coupon_title in F:\server\htdocs\coupon\admin\mnagelist\listing.ph p on line 472

Notice: Undefined variable: description in F:\server\htdocs\coupon\admin\mnagelist\listing.ph p on line 472

Notice: Undefined variable: category in F:\server\htdocs\coupon\admin\mnagelist\listing.ph p on line 472

Notice: Undefined variable: valid_from in F:\server\htdocs\coupon\admin\mnagelist\listing.ph p on line 472

Notice: Undefined variable: valid_thru in F:\server\htdocs\coupon\admin\mnagelist\listing.ph p on line 472

looks like these variables are not in the post. do a little loop check. also, these are only notices, not failures, in the script. You can hide these by setting

error_reporting(E_ERROR);

at the top of the page or better yet in a prepend file. This will simply hide any warnings or notices but display errors. Hiding these types of warnings or for that matter all errors, on a production server is a good idea. When errant warnings go off it's not only ugly but it gives away information about your code.

icandothat is right.. you're using a GET method which is definitely does not coincide with your variables declaration that which POST is being used.. and read some basics for ISSET..

===============================================

I'll take a guess. Since all of the get/post data are undefined (mode could be get and the rest could be post), it is likely that the form and form processing code is in the same file and the form processing code is being unconditionally executed or that the "form" is improperly coded.

You would need to post at least your form code and/or all of your code to get more specific help with it.

Warning and notice messages indicate either improperly written code or data (missing or unexpected content) that the code was not written to handle properly. Turning off warning/notice messages (they are still written to the log file, slowing everything down and filling up the log) just hides what is really wrong with the code and in this case would have gotten a "why is my query not inserting into my database" or if only the mode variable worked "why are the values in the record null" questions.

Code can and should always detect if a variable is set (and for variables from outside your code, validate them to insure they don't contain spam/code injection) before blindly using that variable and code can and should always test if a function call returned a false/failure value before blindly proceeding with using the results from that function call. Easily, 85% of the msyql problems in programming forums are found by adding error checking and error reporting to the msyql_query(...) function call.

There are only a few cases where code cannot detect/validate for a condition that would generate a warning/notice, such as when accessing a remote file and the remote server might be down... In the few cases where properly written code can generate a warning/notice, use the @ to suppress the possible error, but then test for the false/failure value that would be returned by the function call and output a meaningful user message - "could not connect..."

Sorry to turn this into a lecture on error checking and error reporting in properly written code, but in development and learning situations, until code has been throughly tested and is ready for release, everyone should be getting PHP to help find parse and runtime errors by turning on full error reporting. Once code has been tested with every possible what-if data input and is bullet-proof (tests data and function calls and outputs meaningful error messages) you won't care what the error reporting settings are on a production server, because your code won't be triggering any PHP warnings/notices...

I agree with the spirit of your post but in the end I want my production server to hide errors. If one slips past me I don't want the world seeing it. However, on my dev server I have error_all set. PHP should really be written like C where variables are declared before use.

exactly!

There's way more trouble than that here. What good is eliminating notice errors if the script is wide open to SQL Injection. Never put values directly from input $_GET, $_POST or $_COOKIE into an SQL query. They must be escaped with an escape_string function appropriate with the database system you are using (not addslashes, magic_quotes or htmlspecialchars or any other non database encoding). Your server will get owned in short order, if you don't.

escaping does very little to protect you from sql injection. Well constructed queries and logic are your best protection.

I can scarcely believe you said that. Have you even researched the subject?

It doesn't matter how you "construct" a query. If someone wants to insert syntactically correct SQL into an input control on a form, and you don't escape certain characters that are part of the SQL language to guard against it, your server is wide open to attack. Using mysql_real_escape_string or prepared statements with MySQL is the only way to avoid such attacks.

Addslashes and magic_quotes_gpc are vulnerable because they do not take character sets into account. This link explains the vulnerability.

I am shocked that as a mod on this forum, you aren't aware of this.

I am perfectly aware of the dangers of sql injection. To that end, one is better off avoiding the problem rather than just fighting it head on. Case in point. In a login script one might do something like this.


now the code above has a few issues but the one I want to illustrate is the potential for SQL injection. someone could make their password something like
"bob or password is not null"
(This is off the top of my head so you'll forgive me the small leap of logical faith)
You could try to escape the $_POST values and be very clever but there is generally someone out there more clever than you, well at least than me.
However you could appraoch it thusly




in this way you avoid the problem rather than taking it on head on.

Of course I would never recommend inserting values directly from the post without escaping them but that was not the original posters question so I didn't address it. I was not trying to give the impression that cleaning your data is not important.

Finally, Many times people do not post their actual code here but instead a version of it that gives the general idea what what they are trying to do. It's pointless to pick apart every little detail of a post.

I'm aware that sometimes people post "test" scripts to a forum as are you, but many new coders are not. There are far too many tutorials and books out there that still teach the same insecure practices over and over. it gives the language a bad rep which effects client's decisions to use PHP and makes 3rd party code a dangerous mess. We are also all consumers on the web, we even give personal infomation to this site, so we do have a stake in how other coders program web apps.

One misinformed coder could wipe out everything a person owns, if they have our personal information in their hands. Thus it is incumbent on the developer community to try to head these things off. Even if we occasionally offend in the process.

If a new coder doesn't have a grasp of PHP notice errors, they certainly won't understand automatically, any SQL "tricks" to somehow avoid escaping values. The simplest is with numerical data and using intval or force casting. We know this stuff they don't. Not saying anything at all is a little risky.

When someone says "Yeah, i know, i figured i would worry about security later.". Okay, maybe they will, maybe they won't, do they even know what "security" in PHP means.

Saying that escaping does "little" to combat SQL injection is simply false. The SQL parser will not execute any escaped SQL any more than the PHP parser would execute escaped PHP code. Until I hear otherwise from the likes of Mr. Shiflet or other established PHP security experts, I would be foolish to think otherwise.