benanamen
-
Posts
2,134 -
Joined
-
Last visited
-
Days Won
42
Posts posted by benanamen
-
-
You would need a joiner table like player_shirt so there can be multiple players on multiple teams. Pretty basic database design. So it would be like players_to_teams table with team_id and player_id. This would allow an unlimited amount of players to be on an unlimited amount of teams.
-
Using extract like that is bad practice. All of a sudden your script has variables that just magically appear out of thin air. It will make debugging much harder to do when you don't know where stuff is coming from especially when the code base grows. Your active column should be 1 or 0, not Y and N and column type tinyint. You should also explicitly ask for your columns and not use *.
-
OP is about thirty eight (38) versions of mysql behind. The issue in that version of Cent OS has been fixed. He will need to update his sources list and update from the package manager but there could still be an issue because the mysql config path was moved.
-
Try setting max_allowed_packet to 1048576. This is a known problem in that version of Cent OS. If you can, upgrade to CentOS version 7. Did you do a manual Mysql install or from package? If you did manual, you are probably going to have additional problems after the max packet fix but lets see where you are at after the packet increase.
-
You are using obsolete code that has been completely removed from PHP. Hiding errors with @ is a bad idea. You want to fix errors, not hide them, and why in the world are you echoing html? On top of that, page formatting goes in an external CSS file. This code looks like it was written in the 90's. All this x1, x2 x3 is ridiculous.
You need to use PDO with prepared statements.
-
Why did you stop binding the parameters when you got to $getid?
-
For starters try running your code in IE8 and submit using the enter button. It will completely fail.
Another example, If I was to submit your form using cURL, I have no idea that it depends on me also sending a button name to work so it will fail. The field names would be obvious.
-
As a general practice I name all of my submit buttons as "name='btn'".
As Jaques1 has said, depending on the name of a button to be submitted is a bad idea. It wont always be and it will completely fail under certain circumstances. Always use
if ($_SERVER['REQUEST_METHOD'] == 'POST')
along with the hidden input if needed.
-
YOU ARE VULNERABLE TO AN SQL INJECTION ATTACK!
You NEVER EVER send user supplied data directly to the database.
You are using obsolete Mysql code that has been completely removed from PHP. You need to use PDO.
Page formatting needs to go in an external CSS file.
The whole thing needs to be re-written and you need to update all your software versions. You are just begging to be hacked.
-
can you correct this?
$num= $_POST['num']; $CheckNum = mysql_query("SELECT Order from Products WHERE Order = '$num'"); while($test = mysql_fetch_array($CheckNum)) if ($test ) { echo "Is not valide"; }The correction you need is to stop using obsolete code that has been completely removed from the current php version. Use PDO. Your current code is also ripe for an SQL Injection attack. You never ever send user supplied data directly to the database.
-
You are using obsolete mysql code that has been completely removed from php. You need to use PDO with prepared statements.
Here is a tutorial.
-
The
if (isset($_POST['submit']))
would go right above your form processing (which should be at the top of the page code). This is the best solution as iarp mentioned. You would also need { } around your form processing
if (isset($_POST['submit'])) { //all your form processing goes here }No, this is not the best solution since it will completely fail under certain conditions. You are hoping the name of a button is going to be submitted and it wont always be.
The correct method is
if ($_SERVER['REQUEST_METHOD'] == 'POST')
-
echo $foo = '"bar"'; -
<?php
foreach ($result as $row)
{
echo htmlentities($row['message']) .'<br>';
}
?> -
Give this a shot. Without a datadump I couldnt test it.
SELECT u.username, u.email, u.`password`, m.message, g.group_id FROM users AS u INNER JOIN messages AS m ON m.username = u.username INNER JOIN message_group AS g ON g.username = m.username GROUP BY g.group_id ORDER BY m.`timestamp` ASC
-
Your missing url
-
1
-
-
You bound ID but then didn't use it.
-
Is piles of ways can go about it, that's what is great about programming.
Funny you should say that. I have been learning Python the last couple weeks and there is only one way to do it which I am really liking. I have always thought that there were too many ways to do the same thing in PHP and it should just be one way. On several forums I started a post to see how many ways you could output the standard "Hello World!". There are over a hundred different ways. So it really depends on how you look at it as to whether it is great or not.
As far as retaining the correct form values when there is an error, you still can without creating the extra variables like so.
value="<?= !empty($_POST['field']) ? htmlspecialchars($_POST['field']) : '' ?>"
When I said halt the script, I meant the same thing as you.
-
You shouldn't have have a second query or third query. You need to do a single query with a join as I previously posted and you should be asking for specific columns, not using *.
-
Aaarg!
Forget everything I said about the index errors. I shouldn't have even been seeing it. That whole part of the thread is mute and explains why I was thinking we were not quite on the same page. We were kinda having two different conversations.
I was mistakenly doing if field empty set var=. Should have been if field !empty set var=. Doing it !empty as it should have been in this case has the same effect as the parameter not existing at all, coded error gets set either way and script halts.
My normal code pattern is if field false, set error, stop script after all checks run. Quickoldcar was doing if field true set var to post param. I never set vars to a straight POST params unless it has changed for some reason. That's what threw me off.
IMO that formula is no good. For one, you are setting pointless variables to POST parameters that haven't changed, and second, if there is just one parameter error, a whole bunch of already useless variables have been set for no reason.
I believe the proper flow would be:
- Trim the POST array in one step
- Check for empty required fields (has the exact effect if field doesn't exist at all)
- if error add to error array, halt with user friendly errors from array, else continue
-
Rather basic. Add ORDER BY column ASC or DESC. You have too many queries. Just use a join. You are also opening and closing php unnecessarily.
More importantly, you hang pictures on a wall. Next time post your code.
-
Ok, I did some testing on 300,000 employee records. Based on my test results, the fastest option is set an index and no limit 1
No Index Average .97.05541.1421.1551.094.7001.1531.143No Index Limit 1 Average.38.423.354.388.348.412.405.333Indexed Average.026.046.026.022.020.019Indexed Limit 1 . Average 031.020.029.042.038.042.021.029 -
So Jaques1, are you saying that by indexing username there is no reason to use the Limit 1?
I suppose its time I whip out some code and see what actually happens.
-
15 minutes is plenty. My time is either not 15 or I get into an accelerated time warp where 15 minutes seems like 5.
OUTPUT NOT DISPLAYING
in PHP Coding Help
Posted · Edited by benanamen
One other thing not mentioned, you are storing your dates in the wrong format.