Leaderboard

you can examine the data in the database using a tool like phpmyadmin. next, you should have php's error_reporting set to E_ALL and display_errors set to ON, preferably in the php.ini on your system, so that php will help you by reporting and displaying all the errors that it detects. while you are making changes to the php.ini, set output_buffering to OFF, so that any messages from your code or non-fatal php error messages will be seen and not discarded at the header() redirects. you should also have error handling for all the statements that can fail. for database statements, just use exceptions for errors and in most cases let php catch and handle the exception, where it will use its error related settings to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) if you need, someone can post how to enable exceptions for errors for the mysqli database extension or if you switch to the much simpler PDO database extension.

OK, you've created a PHP String variable that just happens to contain some text that your DBMS can make sense of (i.e. you've written some SQL). As others have said, it's very risky SQL, as it stands, but it's still SQL. But it's still only a String variable. You need to tell your database to do something with it (i.e. to execute it). Regards, Phill W.

Don't worry about the IBD file. MySQL knows how to manage itself, you don't need to go second guessing it because of what you think you saw in Notepad. The question you think you're asking is whether to use an UPDATE or a DELETE+INSERT, but the question you're actually asking is how you should manage uploaded files that can be replaced. The answer to that is... well, it depends. There are two basic options: 1. Forget the previously uploaded file. You don't care about it. Take the new file and stick it wherever you want, update the database, and delete the old file. Gotta delete. Because if you forget about the old file then there's not much of a point to keeping the file itself around too. 2. Keep track of the previous file. You'd probably want a table that holds all the information for past and future uploads, and that's where you track them. For using those files, instead of storing the file information in whatever place, you reference the file in your upload information table. New image, new information row, and you update whatever place was affected. This lets you keep a history of everything, which probably isn't important for stuff like user avatars but is frighteningly important for stuff like monetary transactions. "Okay, I've decided that I want to do <whichever option>. But what about my literal question? Should I update or delete and insert?" Time to learn about an important concept in computing that disappointingly few programmers ever end up learning: atomicity. That's the noun version of "atomic", which means (in this case) that whatever operation you need to do can't be interrupted or broken in half or appear to anyone else as being anything less than one single action. Atomicity is important for stuff like files and databases because you basically never want to look at a file or data in the middle of some important operation. Imagine your site is popular. Really popular. Facebook or Twitter popular. Constant traffic to your servers. Now imagine a user uploads a new image. When the code is ready, it needs to go off into the database to make whatever changes it needs to make so the user has the new image. Say you go with DELETE and INSERT. Your code runs one query that DELETEs whatever, then another query that INSERTs. Sounds fine. Except remember how your site is always busy? It's quite possible someone was looking at your site at the moment in between those two queries. Since the DELETE has happened but not yet the INSERT, your code isn't going to find whatever data it needed to find and the user is going to get a bad experience. If that user was a CEO for a huge company that wanted to buy you out for lots of money, they might not do that now. A DELETE and INSERT is not atomic because there was that point in between the two queries. It was not "one single action". Instead you go with UPDATE. The database does whatever it does, but the clever people who wrote the software for it already knew about stuff like atomicity. And they made their system guarantee that UPDATEs are atomic. One single action. If you do an UPDATE when that rich CEO looks at your site, the database has guaranteed to you that either (a) the CEO will see the old data because the update hasn't happened yet, or (b) they'll see the new data because the update has happened. There is no moment in between old and new for stuff to be broken.

You want the Modulo operator.

You have absolutely no code that does anything with your query string. Start with this tutorial and then give it another try. https://phpdelusions.net/pdo

First never, ever put web page data directly into a database. Always use prepared statements. Second, you didn't post the code where you are executing the query. Third make sure error reporting is turned on: error_reporting(E_ALL);

With PHP security, it's important to really learn what you are doing -- no guesswork! If you google "password_hash" you'll see a lot of explanations and examples. In the "olden days" passwords were encrypted, and stored in a database (which could later be hacked). Many encryption functions can result in strings that can be easily decrypted. In fact, there are a lot of websites that will attempt to decrypt your "super-duper encrypted string" for you, and usually do it in about 5 seconds. Nowadays, password "hashing" is popular. The password_hash function uses a random string each time to generate a "hash," which, when tested against the original password (using "password_verify"), will result in either a 'true' or a 'false.' You've noticed when you use "password_hash" you will get a different result each time. That is because this function uses a random string. In the case of your example, "PASSWORD_BCRYPT"). However, regardless how many password_hash results are generated against a specific password, they will all verify as "true." Nowadays, most websites choose to store actual password hashes in databases, rather than actual passwords. Instead of "PASSWORD_BCRYPT" it is popular to use "PASSWORD_DEFAULT" because as new algorithms are invented with PHP upgrades, "PASSWORD_DEFAULT" supposedly uses the latest and greatest. So, if it were me, even though "PASSWORD_BCRYPT" is considered pretty darn good, I would use "PASSWORD_DEFAULT" instead. Again, "security related PHP issues" is not the place to just throw in any line of code you found off the net as one might do when searching for "cool CSS button effects," etc. At the very minimum, do some googling and understand what you are doing. Google "password_hash" "password_verify" and learn all the caveats.

Not to mention the use of TEXT type for names (65,000 character team names! - must be Welsh), dates and scores