I'm a little new to PHP and I have a question.

This is the snipet I'm having problems with:

 CODE

    $name   =   $_POST['name'];
    $price  =   $_POST['price'];
    $item   =   $_POST['item'];
    $date   =   $_POST['date'];
    $query = "INSERT INTO `secondlifetrans` ( `Name` , `Item` , `Price` , `Date` )
VALUES (
'$name', '$item', '$price', '$date'
);";

This, for some reason, outputs empty strings into the sql database, but I'm sure all the variables are completly defined. Any help, anyone?

Well there is two possibilities here. Your server might not allow the use of $_POST you might have to use $HTTP_POST_VARS .

This is highly unlikely unless you are using an older version of php. Any versions before 4.1.0 will use this method but anything after are setup to use $_POST.

The second thing is to add a debug line in there. try doing print_r($_POST); to see if the data Is truely being passed through. If that comes out empty you have a problem somewhere!

Oh I also just caught this:

$query = "INSERT INTO `secondlifetrans` ( `Name` , `Item` , `Price` , `Date` )
VALUES (
'$name', '$item', '$price', '$date'
);";

It Should be:

$query = "INSERT INTO `secondlifetrans` ( `Name` , `Item` , `Price` , `Date` )
VALUES (
'$name', '$item', '$price', '$date'
)";

You added an extra ; in your query line. That will throw an error if you have all yoru error messages on. This is probably the most likely answer for yoru problem.

ctess: semi colons at the end of a query are not a problem (in fact, I think technically they're meant to be there).

The problem could also be: are you sure you're using POST and not GET? What happens if you replace $_POST with $_REQUEST ?

Why do you mix these single quotes ' and these ` ?

Why do you mix these single quotes ' and these ` ?

No problem with that kgun.
I think TwistMyArm is right. The problem is not in this part and we need to know a bit more to answer.

Ok, I have never used those ` quotes and are consitent in my use and use ' and ". Without taking the time to test it, will it say that ` == ' ?

No. (``)s are for table names and field names and ('') are for values.

Look at my question again.

if ur question is "IS ` and ' are same?" my answer is no.
May be i interprited it wrongly, as my english knowledge is not great.

jito is right. I, too, thought you were asking if they were the same and they are not. Normally, you don't see problems with using single quotes all the time, but you are meant to use backticks (`) when referring to table names and columns.

Take, as a really bad example, a table with column 'A' and column 'B'. Imagine you want to set the value of column B to be the same as the value in column A.

By doing something like:
'B' = 'A'
you end up making the value in column B set to 'A' (as opposed to the value in column A).

Instead, you need to use:
`B` = `A`

Strange little things like that... normally MySQL can work out what you're doing, but it does get confused more often than you would expect.

Did you edit your post? I asked is:

`=='

not

`=="

The devil is in the details :-)

I have never used the ` quote in PHP. I use " for values and ' for text strings.

$x1 = 'OOP PHP is cool';

I know the difference between

echo "x1";

and

echo 'x1';

To be more precise is

echo 'x1'; == to echo `x1`;

?

' and ` should have different ASCII codes.

We doubly posted.

i think u have the answer already . think we should stop here and wait for that guy's reply.

Firstly, kgun, you say:

Did you edit your post? I asked is:

`=='

not

`=="

The devil is in the details :-)

But unless jito did edit his post, I don't see either one of us referring to double-quotes. The closest he says is:

No. (``)s are for table names and field names and ('') are for values.

But that last thing in brackets is two single quotes next to each other, not a double quote. The devil is definitely in the details .

Anyway, the backtick is not for strings in PHP. They're for MySQL commands / queries (that, in this context, just happen to be made by the PHP language). Hopefully that clarifies things.

For completeness, backticks are used in PHP for executing shell commands (see http://php.net/language.operators.execution ) but the differentiation that we are trying to make above is purely in regards to MySQL queries. Hopefully that makes a bit more sense!

We learn as long as we live or the opposite. We doubly posted and you answered before I posted my long post.

'' == " ?

There is a difference.

I don't have laser eyes :-)

This is a great thread. Made two new links on my OopSchool, even if it is not very OO. For those interested:

Name of links:

Execution operator.

The devil is in the details.

Now the top two links in the PHP section of the index page.

Eek! Too much activity and path crossing

I'm putting myself in "time out"!

` is COMPLETLY dirrerent to both " and ' !

Thanks for all of these replys. I'll try it and see what I get.

Proper MYSQL Syntax uses backticks to specify the difference between tablenames/rows, etc from variables. I have actually had errors before because I didn't use backticks on some row names because they were the same as a few of my global variables and PHP tried to interpret it funny (I haven't had this problem in php5 only past php versions).

Basicly its for proper syntax. It's like saying why do you use: $array["bleh"] or $array['bleh'] when $array[bleh] works. It's improper syntax and poor coding to use the later version.

As for the original problem You obviously don't see why the semicolon is an issue but lets take a look at his string:

$query = "INSERT INTO `secondlifetrans` ( `Name` , `Item` , `Price` , `Date` )
VALUES (
'$name', '$item', '$price', '$date'
);";

Ok we have the original query, now let's use that query string:

mysql_query("INSERT INTO `secondlifetrans` ( `Name` , `Item` , `Price` , `Date` ) VALUES ('$name', '$item', '$price', '$date');", $db);

See the problem with the extra semicolon now? That will give you nothing.

Also I noticed a formatting problem. General formatting you should always use lowercase for your row names and never capitalize....but it depends on the coder.