benanamen

I am hoping you mean credentials to the application as in a users table in the app DB, which if the case, $_SESSION is how you would do it although putting the password in a session is not what you would do. You could do like $_SESSION['login'] = 1; And then on your pages check to to see if $_SESSION['login'] isset . If you actually mean credentials for a Mysql connection (Yikes! ) then you have some work to do. (As in $con = mysqli_connect("localhost","my_user","my_password","my_db")

What thread are you referring too? If you mean this forum thread, then yes. See attached image for your site.

$cars = array ( array("Volvo",22,18), array("BMW",15,13), array("Saab",5,2), array("Land Rover",17,15) ); function r_implode( $glue, $pieces ) { foreach( $pieces as $r_pieces ) { if( is_array( $r_pieces ) ) { $retVal[] = r_implode( $glue, $r_pieces ); } else { $retVal[] = $r_pieces; } } return implode( $glue, $retVal ); } echo r_implode( '||', $cars ) Result: Volvo||22||18||BMW||15||13||Saab||5||2||Land Rover||17||15 Source:http://www.craiglotter.co.za/2010/04/09/php-implode-a-multi-dimensional-array/

As @cobusbo said, remove StudentID and the NULL entry. What you have is old school Mysql functionality as far as using the null on an auto-increment column as you have it. Newer version Mysql wont work, dont remember what version that changed, nevertheless, it is completely unnecessary.

Additionally, I don't see you doing anything at all with the subjects posted from the form at the top of the page. When you do this up right, you will have another table called subjects or categories and pull from that for your drop down using the subject_id as the drop down value, not the subject description as you have now. Same thing for question types. Also, there is no need to have the mc_id:value = null in your insert query. I am assuming you have it correctly set as auto-increment.

Your server has several security issues and you are vulnerable to click-Jacking.

Your DB structure is not scale-able. You should have separate tables for questions and answers with a foreign key tying them together.

Actually there are several problems with it. Your code is obsolete and will not work in PHP7. It is insecure and you should not be using it. You need to use PDO with prepared statements or at the least Mysqli with prepared statements. SHA1 is not secure, you should be using Brypt.

Okay @Jacques1, We have a winner! After a little research and testing, set_exception_handler is clearly the better way to my global error handling and does eliminate the need for all the try/catch blocks and will still allow me to handle my errors the custom way I need to. Since I already have a config file that is required everywhere, I dont really need to prepend anything. I can just call set_exception_handler from there In all honesty, that is a function I was unaware of. I will be updating my code accordingly. I know a lot but I dont know everything. Always willing to learn.

Looking into it. I am all about using the least yet correct amount of code to get the job done while also considering maintenance. For now my main concern on this app is fatal errors. * Thanks for the Sentry link.

In theory that is great, and is exactly what I do but I should have prefaced, that the app that code is from is in CONSTANT flux on a daily basis as well as the DB structure due to the client coming up with stuff as they use it so query errors are quite common place in this instance. Many, many things are tightly integrated with conditions galore, per the clients business rules and a simple change or addition in one place can easily break something somewhere else. (I personally wouldn't do what they have me do and it is truly the most complex app I have done in my 17 plus yrs coding). The DB schema is an Enterprise Party Model structure due to their business requirements.

In production you never do this as I am sure you know. In dev, of course I have everything turned full on. As I said, I am not the user, so I would never see the displayed error messages and I dont want the user to see it either but I do need to know about it as soon as it happens so it can be fixed immediately. The only errors I need to know about right away are query errors. Anything else I read the last X lines of the particular apps error log. Since there a couple large apps on the same server I send the errors to a custom error log just for that app so I dont have to sort through what errors came from what app. I am assuming you are knowledgeable as an Advanced member, so please share what you would do for the following requirements. 1. Admin needs to be notified immediately of query problem. (Downtime for my apps cost big bucks) 2. Admin needs to readily have available the details to fix problem 3. User should not see server error message but needs to know there was a problem 4. App is to have its own error log. By all means, if you have a better way, I will adopt it in a heartbeat.

Your example is ridiculous! The multiple try catch's you show is not needed and you know full well that is not how it is used. You only need one. As far as query errors, It will tell you exactly what the problem is and where it is. And what part of your solution will notify you as soon as there is an error when you are not the user? The exact purpose of a try catch block is to catch the errors and handle it as you see fit. Since I am not the user of the app, I want to know as soon as it breaks and not hope a user is going to be able to contact me and tell me the details I need. The OP's example uses try/catch executing a query which is exactly where I use it. Not with this random action or that random action which is why the "Obsession" with PDO exceptions. For a database driven application query exceptions are everything. As an include, the code is hardly cluttered in the file it is used in. Write once, use everywhere. My code is an even more controlled manner. It is not going to display error messages to the user except "Fatal Error! Admin has been notified".

That is completely wrong. The catch part of the "try" will give you all that information if you do it right. You cannot have the catch without the try. The code below is included in my catch. It will tell you all you want to know and more. (filename, line number, stack trace, error message) There is also additional code in the include to optionally log and or email the exception data. I get notified automatically if something breaks, whether error details are displayed to user or not. try{ //some bad action here } catch (PDOException $e) { include_once('./config/pdo_catch_error.php'); } pdo_catch_error.php $error_msg = $e->getMessage() . ' in ' . $e->getFile() . ' on line ' . $e->getLine(); if (DEBUG == 1) { echo '<div class="error_custom">Error Message:<br>'.$error_msg.'</div>'; echo '<div class="error_custom">SQL Statement:<br>'; echo ''.$stmt->debugDumpParams().''; echo '</div>'; echo '<div class="error_custom">Stack Trace:<br>'; foreach ($e->getTrace() as $trace) { echo $trace['file'] . ' Line #' . $trace['line'] . '<br>'; } echo '</div>'; } //DEBUG == 1 //Email Error - suppressed error message to user with @ if no mail server. if (EMAIL_ERROR == 1) { @error_log("ERROR: $error_msg\n", 1, "$email_admin", "From: $email_to"); } //EMAIL_ERROR == 1 // Write error to log if (LOG_ERROR == 1) { error_log("$mysql_datetime|$error_msg\r\n", 3, "$errorlog_path"); } //LOG_ERROR == 1 die('<div class="error_custom">Fatal Error! Admin has been notified</div>');

You have a few server security issues. Your site is vulnerable to Click Jacking. You are advertising your PHP version (PHP/5.3.29) Your PHP version is out of date. Current Stable PHP 5.6.13 You are vulnerable to cross-domain Javascript inclusion (Host your JS on your server instead of linking to someone else's server.) Auto Complete is not disabled for your registration fields. Additionally, you are repeating ID's. You can only use the same ID once in a page. (newlife-search-form-block, searchform, s) You have many ending </p> tags with no opening <p> tag

You have a few server security issues. You are advertising your PHP version (PHP/5.4.44) Your PHP version is out of date. Current Stable PHP 5.6.13 You are vulnerable to cross-domain Javascript inclusion (Host your JS on your server instead of linking to someone else's server.) Auto Complete is not disabled for your login and registration fields.

You have a few server security issues. 1. Your site is vulnerable to Click Jacking. 2. You are advertising your PHP version (PHP/5.3.29) 3. Your PHP version is out of date. Current Stable PHP 5.6.13 4. You allow directory browsing. http://weightroom.uk/css/ & http://weightroom.uk/img/ 5. You are vulnerable to cross-domain Javascript inclusion (Host your JS on your server instead of linking to someone else's server.) 6. Auto Complete is not disabled for your login fields.

Sounds like your DB structure is not right. Post your DB schema for us to review.

You have not provided the type of database you are using nor your current code. You need to help us to help you. It is basically just adding a WHERE condition to your sql. SELECT * FROM your_table WHERE location ='Hyderabad'

The jist of your request doesn't make much sense. What are you trying to accomplish overall?

I disagree. You should ALWAYS have the database do the work when it can.

It would look something like the following: * There are many PDO tutorials available. Google is your friend. try { $sql = "SELECT * FROM admin WHERE username=? and password=?"; $stmt = $pdo->prepare($sql); $stmt->execute(array( $username, $password )); } catch (PDOException $e) { // Handle error here. }

The Mysql code you are using is obsolete and insecure. It has also been removed from Php ver 7. You need to be using PDO with prepared statements or at the least Mysqli. Your connection code should only be in one place and included where you need it. As is, you need to do updates in three different places if anything changes. Your code is vulnerable to SQL injection. You are sending user supplied data directly to the database. You should not be using this code at all. There is also no need to create extra variables on your insert. Additionally, there is no need to close the connection. It is automatically closed after the script runs.

Thank you @Zane

$number_value=6; foreach(range('1', $number_value) as $number) { echo "<option value=\"$number\">$number</option>\n"; }