btherl

Please show us the source code. We can't do anything except guess unless we see it.

There is a BIG problem there. In order for headers to work, you must see nothing when you do "view source". Did you follow these steps? 1. Comment out the header() call, but leave exit() there 2. Submit the form with data that should trigger the redirect 3. Use "view source" At step 3, you should see an empty page. If you don't, then alter your script so you DO see an empty page. If you see an empty page but still have the header error, then you probably have some "invisible" output, like a space or a newline. Is there anything before your starting "<?php" tag? By anything I mean anything, even a single space or a blank line.

The manual is here: http://dev.mysql.com/doc/refman/5.0/en/alter-table.html

Try commenting out your header() call (so it simply exits without trying to redirect) and take a look at the source of your page from the browser. There's probably something displayed there. That's what you need to get rid of. It may be blank spaces being displayed.. if so, you need to get rid of THEM too Use the "View" menu in the browser to access the source.

As an aside, the === operator will check both value and type. Using that instead of == will show you when there are typing differences. There's also a corresponding !== operator. I use === by default, unless I am absolutely sure I want == for a specific case.

Have you read http://www.phpfreaks.com/forums/index.php/topic,37442.0.html ?

Is your form supplying the address to your script? Check your form for something like <input name="address" type="text">

PHP is one of the easier languages to learn.. still, you will need to work hard at it. I would suggest daily study and practice if you're going to use it in your job. Yes, primary_mst is the table name. box_addr_stop is a "column" of the table. Tables consist of rows, and each row has columns. For example, an "employee" table would have one row for each employee. And each row would have a column for "name", "address", "phone", etc etc. Based on your questions here, I suggest you do a tutorial on MySQL. I think that's the fastest path to being able to understand this query.

We need you to tell us the error message you get. What do you see when you run this script?

Can you tell us what you expect your code to do and what it actually does? We are not mind-readers

Breaking it down, it has these elements '** ERROR ** NULL Character in : primary_mst.box_addr_stop=' || box_addr_stop This is concatenation. It sticks together that constant string along with the value of column box_addr_stop select distinct This means duplicate rows will only be shown once. '** ERROR ** NULL Character in : primary_mst.box_addr_stop=' || box_addr_stop Alert This means the output will be named "Alert" when you go to fetch it in php after running the query. There is an implicit "AS" which can be left out. I can't help you with the "substr(...) is null" part.. you might want to try a few queries in phpmyadmin to see when substr() gives null on certain inputs.

That's quite complex.. it's more an SQL question than PHP too. Are you using MySQL in your course?

It's a matter of style really.. I use #2, but I don't use sprintf(), I just concatenate the query together placing the variables in place. $powerpuff = mysql_real_escape_string($powerpuff); $sql = 'SELECT foo ' . ' FROM bar ' . ' WHERE bubbles =\'' . $powerpuff_esc . '\''; Something like that.. it's quite readable in an editor with highlighting. I would go for another approach if highlighting was not available though, as it looks yucky without.

What html does the PLS file contain?

I assume you mean 7 of 25 columns, not 7 of 25 rows?

Hmm.. aren't those the same results, just in a different order? Is it important for you to have your results in order of id?

What results do you get if you do onle one of the left joins at one time? For each table you are left joining with. That is, 3 seperate queries.

Try this: $foo=$var1; $bar=$var2; include "./file.php"; $foo and $bar will be available inside file.php

ok, understood You have two options here.. one is to pay someone else to do it (and risk having them bolt again). The other is to learn enough yourself that you can fix it with our assistance. What we probably won't do (unless we're bored) is fix it completely for you, but we can guide you on what to do and what to learn to fix it yourself. Can you add this code into your script: $sql .= $sql2; echo "<pre>"; echo "$sql\n"; echo "</pre>"; The first line is already in your script.. I included that to show you were to add it. Then, copy and paste the EXACT output and post it here. It should look like "CREATE TEMPORARY TABLE ...." and a whole lot more, and may be a few lines long.

Then you've got no problem, as long as you use a salt to avoid the "rainbow table" method described in the wikipedia article. The attack described in wikipedia is for the situation where you are using an MD5 hash to verify a file, and someone is attempting to create a different file with the same MD5 hash.

It means this: If the database query gave no results, then echo "<script ..." Otherwise, if there WERE database results, do nothing. The person who wrote it is using the fact that "0" is treated as "false" by php.

Try this: $str='<img src="captcha.php?width=100&height=30&characters=5" alt="captcha" align="top" />'; $result = preg_match('|<img src="captcha.php\?width=100&height=30&characters=5" alt="captcha" align="top" />|', $str); print "$result\n"; I am using | for the preg delimiter, so there is no need to escape the "/" inside. The only thing needing escaping is the "?", which is a regex metacharacter.

What is your application? Authenticating files or obfuscating passwords? The attack described in the article demonstrates that MD5 cannot effectively authenticate files, but it doesn't show any weakness in MD5 as used for obfuscating passwords.

If the html format is stable and simple (as it appears to be), you can get away with something like this for each line: if (preg_match('|<li>([^<]+)</li>|', $line, &$matches) === 1) { print "Matched {$matches[1]}\n"; } While preg_match() may not be as fast as using low-level string manipulation, it's still quite fast, it's simpler and more flexible. The other option is doing full HTML parsing, but I don't think it's necessary in your situation.

Have you tried printing out all your mysql queries (for both the call that works and the one that doesn't) and inspecting them? Often you can see what's wrong when you take a look. Edit: The other approach I use to fix 90% of my bugs is just to print out the value of variables throughout the script, using var_dump() or print_r(). Most bugs can be fixed this way. You can print out "< pre >" just before dumping the data to make it readable on an HTML page.