mac_gyver
-
Posts
5,372 -
Joined
-
Days Won
173
Posts posted by mac_gyver
-
-
45 minutes ago, anandi said:
I changed to <?php echo $userid ?> . That's one issue solved
you need to fix all the occurrences of short opening php tags. the occurrences in the form that isn't working are probably breaking the html markup and preventing the form fields from being recognized.
you can check what the submitted form data is by adding the following near the top of the php code -
echo '<pre>'; print_r($_POST); echo '</pre>';
47 minutes ago, anandi said:for sake of brevity I didn't copy all of the code here.
by doing that, you prevented anyone here from directly helping and wasted the time of those that looked at the posted information. you have some sql related code in a html context, some form fields outside of any form, form data that you state work without existing in any of the posted code. if you want actual, direct help post all the code needed to reproduce the problem.
-
updating old mysql_ based code requires more than just making it work. you must also make it secure. php's magic_quotes, which provided some protection against sql special characters in string data values from breaking the sql query syntax, which is how sql injection is accomplished, has also been removed. the best choice for updating old application code is to use the PDO extension and use prepared queries when supplying external, unknown, dynamic values to the query when it gets executed.
since you must go through all the database specific code, you might as well future proof it by switching to the much simpler and more modern PDO database extension.
if you use the PDO extension, when you make the connection, set the character set to match your database tables, set the error mode to use exceptions, set emulated prepared queries to false, and set the default fetch mode to assoc. for prepared queries, use simple positional ? place-holders and use implicit binding by supplying an array of input values to the ->execute([...]) call.
-
the code for any page should be laid out in this general order -
- initialization
- post method form processing
- get method business logic - get/produce data needed to display the page
- html document
the post method form processing should -
- detect if a post method form was submitted
- keep all the input data in an array variable, then operate on elements in this array variable throughout the rest of the code
- trim all the inputs at once. after you do item #2 on this list, you can accomplish this with one line of code
- validate all the inputs, storing user/validation errors in an array using the field name as the array index
- after the end of all the validation logic, if the array holding the errors is empty, use the form data
- if an insert or update query can result in duplicate data, detect this in the error handling for the database query, and setup a message for the user telling them what was wrong with the data that they submitted
- after the end of the form processing logic, if there are no user/validation errors, perform a redirect to the exact same url of the current page to cause a get request for the page.
- to display a one-time success message, store it in a session variable, then test, display, and clear the session variable at the appropriate location in the html document.
- if there are errors at item #5 or #7 on this list, the code will continue on to display the html document, redisplay the form, where you should populate the form field values/selects/checkboxes with any existing values so that the user doesn't need to keep reentering/selecting/checking data over and over.
you should get your code to fully work first with one form field, then one field of each type, before you worry about all the code needed for all the rest of the fields.
you can use the following to display what post data is being submitted to your code -
echo '<pre>'; print_r($_POST); echo '</pre>';
the posted code contains a php syntax error on line #13. to get php to display syntax errors, you must set php's error_reporting to E_ALL and display_errors to ON, in the php.ini on your development system (putting these settings into your code won't work for php syntax errors since your code never runs to change the settings.) stop and start your web server to get any changes made to the php.ini to take effect and confirm that the settings actually got changed by using a phpinfo() statement in a .php script file.
you should also validate any resulting web page at validator.w3.org to help make sure the markup is valid and you should only write markup that is necessary.
-
1
-
26 minutes ago, Niss3 said:
in the PHP file
putting the settings in your php code won't help with php parse errors in that file, which was one of the problems in this thread, since the code never runs to change the settings. putting these settings in the php.ini will cause ALL errors to be reported and displayed. it also allows you to change the settings at a single point, so you don't need to go through and edit your code when you move it to a live/public server, where you DON'T want to display all errors, you want to log them.
-
44 minutes ago, Niss3 said:
$opendb = NEW PDO('mysql:host=$dbhost;dbname=$dbname','$dbuser','$dbpass');
php variables are not replaced with their value unless the string they are inside of uses initial/final double-quotes. also, when you have just a variable, e.g. the $dbuser and $dbpass, don't put quotes around it/them at all.
several of the things you have posted should have been producing php errors. do you 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 it detects?
the PDO extension is much simpler, more consistent, and more modern than the mysqli extension. if you are just starting out, forget about the mysqli extension.
when you make the PDO connection, you should name the variable holding the connection as to what it is, such as $pdo. you should also set the character set to match your database tables, set the error mode to use exceptions, set emulated prepared queries to false, and set the default fetch mode to assoc.
don't bother catching any database exception unless it is for something that the user to your site can recover from, such as when inserting/updating duplicate or out of range data. in all other cases, simply let php catch and handle any database exception, i.e. don't put any try/catch logic in your code.
you should always list out the columns you are SELECTing in a query and build the sql query statement in a php variable.
29 minutes ago, Niss3 said:border="0"
this is obsolete markup. use css instead. you should validate your resulting web pages at validator.w3.org
29 minutes ago, Niss3 said:$field1name = $row["col1"];
don't copy variables to other variables for nothing. this is just a waste of typing. just use the original variables.
29 minutes ago, Niss3 said:mysqli_free($result); } mysqli_close($opendb);
in most cases, there's no need to free result sets, free prepared query handles, or close database connections, since php will destroy these when your script ends.
-
the main point behind just attempting to insert the data and test for a unique index error, is because your database must enforce uniqueness. it is the last step in the process. when there are multiple concurrent requests to your current code, a race condition exists where all the instances will find from the SELECT query logic that the value doesn't exist. they will then all attempt to run the INSERT query, resulting in either duplicate data (if your column(s) are not defined as unique indexes), or the first query will win the race, with the others resulting in duplicate errors. since your database must enforce uniqueness, you might as will eliminate the initial SELECT query, since it isn't doing anything useful.
as to why your current code with the SELECT query, which you are going to eliminate from the design, isn't finding if the value exists, is because php variables/class-properties are not replaced with their value when enclosed in over-all single-quoted strings. had you used a proper prepared query, which the first code at the top of this thread was doing, this problem wouldn't have occurred.
also, the name column should be defined as a unique index as well, i.e. both the sku and name must be unique.
7 hours ago, Borkg85 said:I was thinking of doing jQuery validation for required inputs, before posting
client-side validation is a nicety for legitimate visitors. data submitted to your web site can come from anywhere, not just your code, can be anything, and cannot be trusted. you MUST trim (mainly so that you can detect if all white-space characters were entered), and validate the data on the server before using it.
-
// before the start of the loop, set a variable to the unique/one-time output you want. $first = 'class="active"'; while($row = mysqli_fetch_array($result)) { // echo that variable at the point where you want the output ?> <li><a id="<?php echo $row["urlName"] ?>Tab" <?=$first?> href="#<?php echo $row["urlName"] ?>Content"><?php echo $row["title"] ?></a></li> <?php // then set that variable to an empty string after the point where you echo it. every pass through the loop after that point will echo an empty string, i.e. nothing will be output. $first = ''; }
-
no. it's not more easy.
-
before the start of the loop, set a variable to the unique/one-time output you want. echo that variable at the point where you want the output, then set that variable to an empty string after the point where you echo it. every pass through the loop after that point will echo an empty string, i.e. nothing will be output.
-
in a copy of my original posted code, search for every place where $post exists and what related comments there are in the code. see where it is defined and initialized to an empty array? see where it is assigned a value from the array_map() call? see where elements of it are tested in the validation logic? see where elements of it are displayed in the form field value="..." attribute? do the same for the $errors variable. see where it is defined and initialized, elements of it are assigned a value in the validation logic, where it is tested after the end of the validation logic, and where it is tested and displayed in the html document? if you are not understanding and following how these two variables are being used throughout the code, you will not be able to do this activity.
-
On 10/13/2022 at 1:47 PM, rocky48 said:
With so many else statements I am very confused as to where the braces should go!
there shouldn't be else statements in the validation logic, unless they are for different validation steps for the same input, such as for the first name, where you should setup a specific message for each possible validation error telling the visitor what was wrong with the value they submitted. a required value that is empty, or it too long, or contains characters that are not permitted need three different error messages. validating independent/separate inputs is NOT mutually exclusive. you are to validate each input separately, storing any validation error in the $errors array using the field name as the array index.
by using else statements, only the first validation error will get setup and displayed, requiring the user to resubmit the form over and over for each different validation error.
also, by no longer trimming and keeping the form data as a set, in the $post array, none of the field value='...' attributes will get populated with the existing data upon an error.
you are making syntax and logic changes where none is needed.
-
you should be learning, developing, and debugging your code/queries on a localhost development system. trying to use public/online hosting is a waste of time, constantly uploading, and making sure there were no upload errors, to see the result of each change. until your code is secure, this opens the possibility of your web hosting getting abused by hackers. also, most cheap shared web hosts disable things like php's error related settings and database error settings that you need in order to get php and your database statements to help you. they also set disk and web server caching so that you won't immediately see the result of changes you make to your code.
the database hostname on shared hosting is generally not going to be localhost. your web host should have an FAQ section that gives examples of connection credentials. the control panel where you created your database user/password should also list the hostname/ip address to use and any prefix for the username.
if you can setup php's error related settings, you need to set error_reporting to E_ALL and set display_errors to ON. these should be in the php.ini on your system so that they can be changed at a single point.
next, you always need error handling for statements that can fail. for database statements that can fail - connection, query, prepare, and execute, the simplest way of adding error handling, without adding logic at each statements, is to use exceptions for errors and in most cases simply let php catch and handle the exception, where php will use its error related settings (see the above paragraph) to control what happens with the actual error information (database statement errors will 'automatically' get displayed/logged the same as php errors.) to set the error mode to exceptions for the mysqli extension, add the following line of code before the point where you make the database connection -
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
lastly, if you are just starting with php/MySql, learn and use the simpler and more modern PDO database extension.
-
the catching of the database statement error would be in the server-side code, where you would detect if the error number is for a duplicate index error, and setup a message telling the user what was wrong with the data that they submitted, which in this case would be that the sku already exists.
here's the whole story - you always need error handling for statements that can fail. for database statements that can fail - connection, query, prepare, and execute, the simplest way of adding error handling, without adding logic at each statement, is to use exceptions for errors and in most cases simply let php catch and handle the exception, where php 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.) the exception to this rule is when inserting/updating duplicate or out of range user submitted data values, which are the only kind of database errors that the 'user' on your site can recover from (all other database errors are either due to programming mistakes, the database server not running, or nefarious activity, that the user doesn't need to know anything at all about), by potentially entering new value(s) and resubmitting the data. in these cases, your code would catch the exception, test if the error number is for something that your code is responsible for handling, and setup a message for the user letting them know what was wrong with the data that they submitted. for all other error numbers, just re-throw the exception and let php handle it. you would set the PDO error mode to exceptions when you make the connection.
the net result of submitting the form data to the server-side code for this Create/insert operation should be either a success value/message or failure message(s) - consisting of all the user/validation errors. since you are making an ajax request, you should create an array with a 'success' or 'error' key, with the appropriate values, json_encode() this and output it to the browser for the ajax success code to test and use.
some points about the posted code -
- OOP is not about wrapping a class definitions around parts of your main code and adding $var-> in front of everything to get it to work. all this is doing is exchanging one defining/calling syntax for another one, taking 2-3 times the amount of typing to accomplish a task.
- you won't be using a SELECT query anymore for this current operation, but when you do use a select query, list out the columns you are selecting. for cases where you just need a count of the number of matching rows, use a SELECT COUNT(*) ... query, then fetch and use the count value. related to this, the rowCount() method may not work for a data retrieval query for all database types, and should be avoided for these type of queries. you should always fetch all the data that a query returns (the current code should be producing an out of sync error since you didn't fetch the row(s) of data from the select query.) also, for a select query, the only variable name that must be unique is the final variable holding the data fetched from the query. just use simple names like $sql, $stmt, ... for the variables in the common code.
- writing out variables/properties by themselves does nothing (doesn't even produce any php byte code.) why do you have those 9 lines in there?
- if you use simple positional ? place-holders and implicit binding, by supplying an array to the ->execute([...]) call, it will save a ton of repetitive typing and typo mistakes.
- any php error related settings should be in the php.ini on your system so that they can be changed at a single point. having a display_errors setting inside some conditional logic in your code makes no sense.
-
1
-
the getLocationInfoByIp() function call is returning a boolean (probably a false value), so the array dereferencing of the returned value, e.g. the ['country'] element, is also failing. you would need to determine why the function call is failing. you also always need error handling for statements that can fail so that your code doesn't attempt to use non-existent data.
-
<script> const format = (num) => new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(num); </script>
replace $('#totalPrice').text(totalPrice); with $('#totalPrice').text(format(totalPrice));
-
the comma thousands separator is a display convention that makes a number human friendly. it has no meaning to a computer and actually breaks the value.
you are calculating and displaying a value in the browser. you must format that number in the browser when you display it.
2 hours ago, Moorcam said:<input type="hidden" name="p_price_single" value="<?php echo number_format($tour['p_price_single'],2); ?>">
i hope you are not planning on using the price from this hidden field, as it can be set to anything, such as .01, in the submitted data. only the id and the quantity should be submitted.
-
13 minutes ago, rocky48 said:
Any suggestions?
the ->execute() syntax is a method/function call. the () are part of that syntax. it takes an array as the call-time parameter.
the example code i posted only needed to have each additional field added to the validation logic, the sql query, and the array of parameters in the ->execute() call. this is a simple A-B pattern matching exercise.
-
the ->execute() method call accepts an array of values that correspond to the ? place-holders in the sql query. The [ and ] you are asking about are php's array definition syntax. the single $post['fname'] variable is a single value/element within that array.
to supply more than one value, you supply more than one variable within that array. if $post['fname'] is one variable and $post['lname'] is another variable, wouldn't that look like [ $post['fname'], $post['lname'] ]
-
all the code needed to search for data already exists. it is called a database engine. unless this is an assignment that requires you to store the data in a file, save yourself the trouble of redesigning a proverbial wheel again and just use a database.
your search form and form processing code should be on the same page, this results in the most secure code, the best user experience, and the simplest code. your search form should use method='get', this is a convention used on the www, where if someone finds a result they want, they can book-mark the url or share the url with others and be able to return to the same result. your search form should be 'sticky' and repopulate the field values with any existing data, this serves to both display the search term and allows the user to modify the search simply by modifying any of the field value(s). once the search form has been submitted, except for unchecked checkbox/radio fields, all the fields will be set, i.e. don't use isset() for every always-set field. if you are selecting from existing data values, rather than free typing values, which should use a wild-card match, you should use a select/option menu.
the code on any page should be laid out in this general order -
- initialization
- post method form processing - used when performing an action on the server, such as inserting, updating, or deleting data
- get method business logic - get/produce data needed to display the page. any code that knows how to query for and fetch data goes here...
- html document
regardless of the data source - database, api that returns json encoded data, a file, the code that knows how to query for and fetch the data belongs in section #3. the output from this code should be an array, that's either empty, if no matching data was found, or an array of rows of the matching data. simple php code in the html document will just test/loop over this array of data to produce the output.
your form processing code should trim, then validate all inputs before using them. if a required field is an empty string after being trimmed, that's an error. you should setup a message for the user telling them what was wrong with the data that they submitted, and not attempt to use the input data at all. if you want your query code to return all data when there is no search input, you will need to write logic to specifically do this.
if you are going to use a file to hold the data, you need to use file locking and have file error handling so that concurrent access to the file won't corrupt the data stored in the file. if you use a database for this, the database engine will take care of any locking needed for concurrent access.
after you explode the data you read from the file, you should trim each resulting element, i.e. don't assume that your file will always have exactly the white-space shown. array_map(), using either one of php's built-in functions or a user written call-back function is useful for operating on data stored in arrays. you could for example write a call-back function to take the result of the file() call, explode, trim, and build associative indexed arrays for each line read from the file.
the reason why it was suggested to get your code to work for one form field, which could initially be any of the fields, is you need to get your code to work at all, with just one field, before you can worry about all the code needed for the other fields.
-
re: your last post above. if you are seeing the form, given that there are php syntax errors still present, it is likely that you are not requesting the page using a url -
15 minutes ago, mac_gyver said:are you requesting your main page using a URL to the web server on your development system? the url should be similar to - http://localhost/your_main_file.php NOT something like file:///C:/xampp/htdocs/your_main_file.php, which is a file system path and doesn't cause the php code to be executed.
-
your posted connection code works for me, so it probably isn't being executed at all.
what output do you get? and if it's a blank page, what does the 'view source' in your browser show?
are you requesting your main page using a URL to the web server on your development system? the url should be similar to - http://localhost/your_main_file.php NOT something like file:///C:/xampp/htdocs/your_main_file.php, which is a file system path and doesn't cause the php code to be executed.
your first posted code contains a number of php syntax errors that will prevent it from running at all. until you actually do item #1 on my list, php will not help you with php syntax errors in all your files because putting the php error related settings in a file won't cause the settings to take effect because the code in that file doesn't run when there's a php syntax error in that file.
beyond the above points, you would need to post your current code to get any help with it.
if you incorporate all the practices listed, which are designed to make your code secure, in all contexts, provide a good User eXperience (UX), by letting the user know when they did something that they can correct and prevent them from having to keep retyping information over and over, result in simple general-purpose code, that doesn't have you typing a bunch unnecessary things that don't contribute to a working application, through the php error related settings (item #1 in my list), the validation logic (item #6), and having error handling (item #9), your code will either work or it will tell you why it isn't.
here's an example showing all the posted points -
<?php // initialization session_start(); // why not have the connection code actually make the connection too, so that you don't need another line of code? require "conn/connect_seniorform.php"; // note: this code uses the much simpler and more modern PDO database extension // when you make the connection - // set the character set to match your database tables, so that no character conversion occurs over the connection // set the error mode to use exceptions, so that all the database statements will use exceptions (this is the default now in php8, but set it anyways) // set emulated prepared queries to false, you want to run real prepared queries // set the default fetch mode to assoc, so that you don't need to specify it in each fetch statement $post = []; // array to hold a trimmed working copy of the form data $errors = []; // array to hold user/validation errors // post method form processing if($_SERVER["REQUEST_METHOD"]==="POST") { // inputs: first_name (add others once code is working) // trim all the input data at once $post = array_map('trim',$_POST); // if any input is an array, use a recursive trim call-back function here instead of php's trim // validate all inputs // first name if($post['first_name'] === '') { $errors['first_name'] = "First Name is required"; } // validate other inputs here... // if no errors, use the input data if(empty($errors)) { $sql = "INSERT INTO senior_dat (first_name) VALUES (?)"; $stmt = $pdo->prepare($sql); // note: the following try/catch error handling deals with having a (single) unique column (email) defined in your database table // if you have multiple unique columns defined, you would execute a SELECT query inside the catch code to find which column(s) contain duplicate values matching the input data and setup an error message for each one try { // a 'local' try/catch to handle a specific error type $stmt->execute([ $post['first_name'], ]); } catch (PDOException $e) { if($e->errorInfo[1] == 1062) // duplicate key error number { $errors['email'] = "Email is already in use"; } else { throw $e; // re-throw the pdoexception if not handled by this logic } } } // if no errors, success if(empty($errors)) { $_SESSION['success_message'] = "Form saved OK"; die(header("Refresh:0")); } } // hrml document starts here... ?> <?php // display and clear any success message if(!empty($_SESSION['success_message'])) { echo "<p>{$_SESSION['success_message']}</p>"; unset($_SESSION['success_message']); } ?> <h1>SENIOR RENEWAL FORM</h1> <?php // display any errors if(!empty($errors)) { echo '<p>'; echo implode('<br>',$errors); echo '</p>'; } ?> <form method="post"> <label><b>First Name:</b><br><input type="text" name="first_name" size="20" maxlength="40" value="<?=htmlentities($post['first_name']??'',ENT_QUOTES)?>"></label> <br> <input type="submit" value="submit"> </form>
if you insist on using the overly complicated and inconsistent mysqli database extension, adding the following line of code, before the point where you make the database connection, will cause it to use exceptions for errors (item #9 on my list) -
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
-
until you get your code to work for one form field, there's no good point in writing out php code and html markup for all the form fields, that you will need to make multiple changes to before getting it to the point of working. pick one field, such as the visitor's last name (most people have two names and your form and database table needs two fields, so that you can distinguish between the first and last name, for example is someone Martin Ross or Ross Martin.)
in the php code, there's actually only one line worth keeping, e.g. checking if a post method form was submitted. you should -
- have any error related settings in the php.ini on your system so that ALL php detected errors will get reported. the initial php syntax errors present will prevent your code from running at all, so any error related settings in your code won't take effect.
- use 'require' for things your code must have for it to work and include/require are not functions. the () around the filename are unnecessary clutter.
- keep the form data as a set, in a php array variable, then operate on elements in this array variable throughout the rest of the code, i.e. don't copy variables to other variables for nothing. this is just a waste of your time typing.
- as has already been mentioned, use $_POST for the post input data. you also have a mistake in the syntax for $REQUEST (there's an under-score after the $, which is another good reason to get your code to fully work for one form field, before worrying about all the code needed for the rest of the fields.)
- trim all the input data, mainly so that you can detect if it consists of all white-space characters, before validating it. after you do item #3 on this list, you can trim all the data at once using a single line of php code.
- validate all the input data before using it, storing user/validation errors in an array, using the field name as the array index.
- after the end of all the validation logic, if there are no errors (the array will be empty), use the submitted form data.
- you should switch to the much simpler and more modern PDO database extension, especially since you will be converting this query to be a prepared query in order to prevent any sql special characters in the values from being able to break the sql query syntax, which is how sql injection is accomplished.
- you should use exceptions for database statement errors and in most cases simply let php catch and handle any database exception. the exception to this rule is when inserting/updating duplicate or out of range user submitted values. in this case, you code should catch the exception, test if the error number is for something that your code is designed to handle, such as a duplicate index error for fields that must be unique, e.g. the email field, and setup a message telling the visitor exactly what was wrong with the data that they submitted. for all other error numbers, just rethrow the exception and let php handle it.
- list out the columns you are providing values for in the insert query. this will let you eliminate things like the id column, which the value you are currently attempting to provide doesn't exist, e.g. there's no id field in the form and any php code referencing it will be producing php errors.
- if you were putting values directly into the sql query statement (you won't be when using a prepared query), you would need to put single-quotes around any literal string values, so that they don't produce sql errors about non-existent columns named the same as the data values.
- not sure why you are applying nl2br() to a value that doesn't have any new-line characters in it.
- after the end of all the post method form processing logic, if there are no errors, you would preform a redirect to the exact same url of the current page to cause a get request for that page.
- any redirect needs an exit/die statement after it to stop php code execution.
- to display a one-time success message, store it in a session variable, then test, display, and clear the session variable at the appropriate location in the html document.
- if at item #7 or #13 on this list, there are errors, your code will continue on to redisplay the html document, display any user/validation errors, redisplay the form, repopulating the form field values/selections with the existing values, so that the user doesn't need to keep re-entering data over and over when there are errors.
- any external, unknown, dynamic value that you output in a html context should have htmlentities() applied to it when it is being output, to help prevent cross site scripting.
- there's no good point in closing database connections since php will automatically destroy everything that was created on a page when your script ends.
-
1
-
what are the php versions of these two systems? the exception is due to php8's revamped error responses, where a number of previous warnings now produce exceptions.
also, the procedural usage of mysqli_connect(), combined with the OOP usage of $link->connect_error is incorrect in any case, since mysqli_connect() returns a false value upon failure.
-
php's error_reporting should (always) be set to E_ALL. when learning, developing and debugging code/query(ies), display_errors should be set to ON. when on a live/public server, display_errors should be set to OFF and log_errors should be set to ON. these setting should be in the php.ini on your system so that ALL php errors will get reported (putting the settings in your code won't cause fatal parse errors to be reported since your code never runs to cause the settings to take effect) and so that they can be changed in a single place. while you are making changes to the php.ini, set output_buffering of OFF. stop and start your web server to get any changes made to the php.ini to take effect and confirm that the settings actually got changed by using a phpinfo() statement in a .php file that you request through the web server.
next, when you make the PDO connection -
- set the character set to match your database tables. so that no character conversion occurs over the connection.
- as already mentioned, set the error mode to exceptions (this is actually the default now in php8, but set it anyways), so that all the rest of the PDO statements, after the connection (which always uses exceptions for errors), will also use exceptions for errors.
- set emulated prepared queries to false, you want to run real, not emulated, prepared queries.
- set the default fetch mode to assoc, so that you don't need to specify it in each fetch statement.
since you are just getting started with the PDO extension, save yourself a lot of typing with prepared queries by using simple positional ? prepared query place-holders and use implicit binding, by supplying an array of input values to the ->execute([...]) call.
Saving to mysql database not working!
in PHP Coding Help
Posted
you are deleting the comments without even reading and understanding what they say.