Jump to content

[SOLVED] Can add date to one table with PHP, but not another


zeek69

Recommended Posts

I have created a database with 2 tables, one is called test with 5 fields and I have a php script that adds data from a form to the database without error. I have a second table with 7 fields with basically the same php script to add data to it, but it won't enter the data. Not sure what is wrong, the tables seem to be setup identically, and are in the same database. Here are the 2 scripts. I figure it is something stupid that is causing this problem, but I have been staring at this for days with no luck. Any help would be greatly appreciated.

 

Zeek

<?

$DBhost = "xxxxxxxx.ipowermysql.com";
$DBuser = "xxxx";
$DBpass = "xxxx";
$DBName = "xxxxx";
$table = "test";

mysql_connect($DBhost,$DBuser,$DBpass) or die("Unable to connect to database");

@mysql_select_db("$DBName") or die("Unable to select database $DBName");

$name = mysql_real_escape_string($_POST['name']);
$email = mysql_real_escape_string($_POST['email']);
$age = mysql_real_escape_string($_POST['age']);
$country = mysql_real_escape_string($_POST['country']);

$sqlquery = "INSERT INTO $table VALUES('$id','$name','$email','$age','$country')";

$results = mysql_query($sqlquery);

mysql_close();

print "<html><body><center>";
print "<p>You have just entered this record<p>";
print "Name : $name br";
print "Email : email br";
print "Age : $age br";
print "Country : $country br";

print "</body></html>";
?>

-----------------------------------------------------------------------------------------------

<?

$DBhost = "xxxxxxxx.ipowermysql.com";
$DBuser = "xxxx";
$DBpass = "xxxx";
$DBName = "xxxx";
$table = "items";

mysql_connect($DBhost,$DBuser,$DBpass) or die("Unable to connect to database");

@mysql_select_db("$DBName") or die("Unable to select database $DBName");

$item = mysql_real_escape_string($_POST['item']);
$high = mysql_real_escape_string($_POST['high']);
$low = mysql_real_escape_string($_POST['low']);
$paid = mysql_real_escape_string($_POST['paid']);
$qty = mysql_real_escape_string($_POST['qty']);
$date = mysql_real_escape_string($_POST['date']);


$sqlquery = "INSERT INTO $table VALUES('$id','$item','$high','$low','$paid','$qty','$date')";

$results = mysql_query($sqlquery);

mysql_close();

print "<html><body><center>";
print "<p>You have just entered this record<p>";
print "Item : $item br";
print "High : $high br";
print "Low : $low br";
print "Paid : $paid br";
print "Qty : $qty br";
print "Date : $date br";

print "</body></html>";
?>

 

Please use code tags when posting code ~ CV

Link to comment
Share on other sites

Crayon,

 

Thanks, with that addition I found out that it was giving me a duplicate entry error. The ID field wasn't set to auto increment. Once I go that resolved, it worked fine. I new it was something simple.

 

Zeek

Link to comment
Share on other sites

Just for future reference...ALWAYS add that line after your queries.  ALWAYS.  It makes debugging so much simpler.

 

Edit: Sorry for being so angry before, lol, but there are at least 5 threads a day that are solved by having them add that line.  It's really annoying after a while. =P

Link to comment
Share on other sites

I disagree. That's a crap way of doing error handling.

 

It makes debugging queries a hell of a lot simpler, especially because it's a MySQL error and not a PHP error, so it won't be sent through any error handlers.  Unless you throw an exception for failed MySQL queries, which I think is overkill and it's only in PHP5+, so therefore he might not be able to do it.  Please explain why it's a crap way of doing error handling.

Link to comment
Share on other sites

Obviously not.  That reveals too much info.  For production sites I use custom error handlers and such, but for debugging, it makes much more sense to handle the error directly.

 

Why not just write the error handler on before hand and use that? The PHP5 argument you used above doesn't hold. PHP has officially stopped supporting PHP4 so there is no reason whatsoever not to upgrade. Furthermore, why do you think exceptions would be overkill?

 

haha yeah I just suggested it to help him find his bug, that's all.

 

Sure, and it did, but he would've been better off designing his application properly from the start.

Link to comment
Share on other sites

Sure, and it did, but he would've been better off designing his application properly from the start.

 

Yeah...tell that to 99% of the people who come here who have no formal education in php or even programming in general.  The bottom line is that they don't care, nor will they ever care.  They want a quick and dirty solution, so I give it as much as possible.  This isn't some hospital or dr's office where people strive to go by the book 100% of the time.  This is a warzone and we're field medics pulling McGuyver-like operations to keep the soldiers up. Suck it up soldier!

 

 

 

 

Link to comment
Share on other sites

Obviously not.  That reveals too much info.  For production sites I use custom error handlers and such, but for debugging, it makes much more sense to handle the error directly.

 

Why not just write the error handler on before hand and use that? The PHP5 argument you used above doesn't hold. PHP has officially stopped supporting PHP4 so there is no reason whatsoever not to upgrade. Furthermore, why do you think exceptions would be overkill?

 

haha yeah I just suggested it to help him find his bug, that's all.

 

Sure, and it did, but he would've been better off designing his application properly from the start.

 

1) Some webhosts don't have PHP 5 yet, sadly.  Kind of strange, but it's true.  Also, like CV said, lots of people on these forums have never even HEARD of exceptions. 

 

2) If he had designed it properly from the start, he wouldn't be posting here.

Link to comment
Share on other sites

Sure, and it did, but he would've been better off designing his application properly from the start.

 

Yeah...tell that to 99% of the people who come here who have no formal education in php or even programming in general.  The bottom line is that they don't care, nor will they ever care.  They want a quick and dirty solution, so I give it as much as possible.  This isn't some hospital or dr's office where people strive to go by the book 100% of the time.  This is a warzone and we're field medics pulling McGuyver-like operations to keep the soldiers up. Suck it up soldier!

 

That's a shame, because I could name a few people (but I won't, at least not publicly) that I would hate to take over a project from. Also, if I were to buy anything I don't just want it to work, I want it to work properly, but the problem is that I'm not competent enough to say if it's good or bad.

 

Obviously not.  That reveals too much info.  For production sites I use custom error handlers and such, but for debugging, it makes much more sense to handle the error directly.

 

Why not just write the error handler on before hand and use that? The PHP5 argument you used above doesn't hold. PHP has officially stopped supporting PHP4 so there is no reason whatsoever not to upgrade. Furthermore, why do you think exceptions would be overkill?

 

haha yeah I just suggested it to help him find his bug, that's all.

 

Sure, and it did, but he would've been better off designing his application properly from the start.

 

1) Some webhosts don't have PHP 5 yet, sadly.  Kind of strange, but it's true.  Also, like CV said, lots of people on these forums have never even HEARD of exceptions. 

 

2) If he had designed it properly from the start, he wouldn't be posting here.

 

At 1: Switch host. They're not worth bothering with. Regarding the exceptions. IMO people should read the syntax chapter of the manual before even trying to create any code.

 

At 2: True, but that's the reason why we should teach them the correct ways instead of just continuing bad practice just because the rest of the application is written so.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.