PatRoy

Say Barand, I've adopted your SQL way in other pages, which I find is great! Wondering though : any idea if MySQL would be able to output the days separated by an hyphen '-' for continuous numbers, and a comma for others ? i.e. +--------------+-----------+------+ | days | month | year | +--------------+-----------+------+ | 8, 10-12, 16 | August | 2020 | | 20, 27-30 | September | 2020 | | 1-2 | October | 2020 | +--------------+-----------+------+ Cheers! Pat

Thank you folks!! I was thinking of Barand's solution and that's what I adopted. I was really tempted to use the SQL way also, but I also need all my dates separately (they are all in a hidden dates[] array for modification with a calendar. I'd have to use 2 sql statements if I wanted just the SQL solution. This is my code : <?php $dates = array ( '2005-05-21', '2020-09-29', '2006-11-02', '2020-09-28', '2020-09-30', '2020-10-01', '2006-11-01' ); sort($dates); // sort oldest to newest $my_dates = [ ]; // re-generate proper dates array [year][month] => array(days...) foreach ( $dates as $d ) { $date = new DateTime($d); $year = $date->format('Y'); $month = $date->format('F'); $day = $date->format('d'); if ( ! isset($my_dates[$year][$month]) ) { $my_dates[$year][$month] = array (); } array_push($my_dates[$year][$month], $day); } // pretty-print the dates foreach ( $my_dates as $year => $monthDays ) { $prettyDate = ''; foreach ( $monthDays as $month => $days ) { foreach ( $days as $day ) { $prettyDate .= "$day, "; } $prettyDate = substr($prettyDate, 0, -2) . ' '; // remove last ',' after days $prettyDate .= $locale->_($month) . " $year <br/>"; // print month and year, with translated month } echo $prettyDate; } ?> Outputs: 21 Mai 2005 01, 02 Novembre 2006 28, 29, 30 Septembre 2020 01 Octobre 2020 Thanks a bunch for your help and time! Pat

Hi, I'm trying to achieve a special output of dates. I essentially have an array of dates like so: // dates in yyyy-mm-dd format $dates = array('2005-05-21', '2006-11-01', '2006-11-02', '2020-09-28', '2020-09-29', '2020-09-30', '2020-10-01'); I need to output theses dates like so: 05 may 2005 01, 02 november 2006 28, 29, 30 september 2020 01 october 2020 I'm really not sure how to go about this. I'm sure this must be possible. Any help would be great!! Thanks a bunch! Pat

Outputs: string(5) "mysql" string(6) "5.5.28" My weird setup is due to the fact that my 'server' is a farely old NAS running a armv5tel architecture Linux. I had 'kinda' jailed broken the NAS as to get custom servers on it (lighttpd, mysql, etc). But the fact that it's jailbroken, and old, limits me on packages and versions I can install on it (thus the reason its running PHP 7.1). It's pretty much a nightmare to try and compile stuff on it because of missing / eventually broken libraries... I think I have no choice but to live with it and accept the returned strings from MySQL by adopting my workaround to do my validation on my property setters only, instead of within my save(). Thanks for your help and times

UPDATE: Upon reading https://www.php.net/manual/en/mysqlnd.install.php, it seems the mysqlnd is enabled by a ./configure option on either mysqli, or pdo_mysql... Looking at the ./configure command options within phpinfo(), I see the following two: --with-mysqli=shared,mysqlnd --with-pdo-mysql=shared,/ffp Would that mean that mysqli has mysqlnd enabled (thus the reason I see it in phpMyAdmin since it uses mysqli), and my pdo_mysql doesn't have it enabled (assuming, since the lack of it in the configure above) ? HOWEVER, if I just do: var_dump(extension_loaded('mysqlnd')); it returns TRUE. So, super confused here... but then again, is it telling me true, just because it's 'loaded' only if using mysqli to query the database?

I'm not sure I understand how to look / confirm I'm using the mysqlnd driver... Even less how to force use it.. I do have extension=pdo_mysql.so loaded in my php.ini, which I thought was loading the mysqlnd driver (guess not!?). And, when I load the web phpMyAdmin to managemy DBs, the homepage does give me some info on the server, one of them being: Database client version: libmysql - mysqlnd 5.0.12-dev - 2015040. See screenshot attachment... Is the mysqlnd loaded 'per web application' ?

PDO PDO support => enabled PDO drivers => mysql pdo_mysql PDO Driver for MySQL => enabled Client API version => 5.5.28

Thanks for your reply! Well, indeed, I do set my DB connection with PDO::ATTR_EMULATE_PREPARES => FALSE. Would that mean that MySQL automatically just return strings, but if allowing PHP/PDO to do the prepares, then IT only can properly prepare and return native datatypes? I had set it to false, in part to protect against SQL Injections, though I don't remember how this worked out for this... To answer others, I needed to resolve this because I am writing my own ORM system, which loads objects from database into an array of properties: array(11) { ["id"]=> array(8) { ["column"]=> string(2) "id" ["type"]=> string(7) "integer" ["readonly"]=> bool(true) ["required"]=> bool(false) ["value"]=> string(1) "1" ["valueIfNull"]=> NULL ["useDBDefaultWhenNull"]=> bool(false) ["datetimeformat"]=> NULL } ["dateModified"]=> array(8) { ["column"]=> string(13) "date_modified" ["type"]=> string(8) "datetime" ["readonly"]=> bool(false) ["required"]=> bool(false) ["value"]=> string(19) "2020-06-07 22:35:24" ["valueIfNull"]=> NULL ["useDBDefaultWhenNull"]=> bool(false) ["datetimeformat"]=> NULL } .... } As you can see, the "value" are always strings. I have a validDatatype() check that validates $value before submitting into the database. To do so, I simply run a check that gettype($value) is the same as my prop "type". Initially, I wanted to do all of the datatype validation within my save() method. However, if when loading all fields are strings, when I go ahead, mod some values, and then save(), it'll fail datatype validation! My current workaround is to do my validation on my property setters only, instead of within the save(), but I still wondered why I was getting all strings from MySQL.... Cheers for your replies! P.

Hello, My current server setup : PHP version: 7.1.4 MySQL 5.5.28 Database client version: libmysql - mysqlnd 5.0.12-dev I'm using PDO _MYSQL to run database queries. From what I read, in order to have MySQL return native datatypes (as opposed to just strings) : if using MySQLi: set $mysqli->options(MYSQLI_OPT_INT_AND_FLOAT_NATIVE, 1) if using PDO and have mysqlnd: "mysqlnd returns native data types when using Server-side Prepared Statements, for example an INT column is returned as an integer variable not as a string." Now, I do have mysqlnd, but a simple PDO Prepared statement still returns me all strings, even though some columns are set as INT, VARCHAR, DATETIME, etc.. $stmt = $pdo->prepare("SELECT * FROM tbl_users WHERE id=1"); $stmt->execute(); $user = $stmt->fetch(); var_dump($user); OUTPUT: array(13) { ["id"]=> string(1) "1" ["is_admin"]=> string(1) "1" ["is_active"]=> string(1) "1" ["username"]=> string(5) "jdoe" ... } I'm not sure what to look for to resolve this issue if I want it to return INT as INT and not STRING, etc. Does having `extension_loaded('mysqlnd') == true`, make my system automatically use this native mysql driver? How can I tell ? Could this be a version problem perhaps? Much thanks! Pat

The idea is to stop the script whenever an error (or exception) occurs. My handler essentially logs the error with a uniqid() to a log file, sends an email to admins with the full error message + ID, and finally, outputs an html page with a generic message "Oh crap! Something went wrong! Contact admins with ID: <error id>" So, from my understanding, I'd need 2 Error Handler classes: one for errors, and one for exceptions.... OR, I guess I could have in my ErrorHandler class 2 functions : /** * Handle Errors: set from set_error_handler() */ public function handleError($errno, $errstr, $errfile, $errline) { ... $this->sendToEmail(); // send email to admins $this->saveToLog(); // save to log file $this->loadErrorPage(); // print error page and exit()! } /** * Handle Exceptions: set from set_exception_handler() */ public function handleException($ex) { ... $this->sendToEmail(); // send email to admins $this->saveToLog(); // save to log file $this->loadErrorPage(); // print error page and exit()! } Would this be a proper way of doing this then ? I do not like having to trigger_error() in my try/catch... For one thing, I think the script should catch any such mistakes, and for another, with trigger_error(), I do not have access to the Exception object (to stacktrace it, etc.). Thanks for your inputs! Pat

I'm sure it's not much, but I'm not understanding something with custom error handlers: I've created a custom error handler, which I initially set when my page loads : set_error_handler(array ( new ErrorHandler(), 'handleError' )); It seems to catch all internal PHP errors, such as if I: var_dump($non_existing_var); right after the set_error_handler.... Now, I have an object that throws an exception after: set_error_handler(array ( new ErrorHandler(), 'handleError' )); $locale = new \CorbeauPerdu\i18n\Locale(...); // this should throw an exception ... I thought that with an error handler set, I could 'skip' the try/catch for it, but doing so, PHP spits out in its internal log: PHP Fatal error: Uncaught CorbeauPerdu\i18n\LocaleException: .... My error handler doesn't catch it at all before, thus my page breaks!! If I want it to go through the error handler, I have to init my Locale with a try/catch and use trigger_error() like so: set_error_handler(array ( new ErrorHandler(), 'handleError' )); try { $locale = new \CorbeauPerdu\i18n\Locale(...); // this should throw an exception } catch(Exception $e) { trigger_error($e->getMessage(), E_USER_ERROR); } ... Is this normal ? I thought one of the goals of the error_handler was to catch anything that wasn't dealt with? Thanks for your answers!

It is still one line more than me, if you consider the fact that I do it the same way with my DBWrapper 😛 But really, this discussion is non-sense and pointless to me, especially if one doesn't even look at the usage examples / documentation and doesn't care to see how it can really help down the line. Again, you take, or not... Whatever suits you, no bad feelings héhé. Cheers. P.

I think you write a bit more than that... Your two-liner code should really be: try { $mydb = new PDO($dsn, $username, $password, $options); $data = $mydb->prepare("SELECT * FROM users WHERE ID = :id"); $data->execute(['id'=>$userid]); } catch (Exception $e) { die($e->getMessage()); } Plus, I was under the impression that it's still better to also bindValue / bindParam, to also set its proper datatype, protecting against SQL Injections, which you are not using... With your way, I have to re-enter all of the DB configs everytime, which is the least of the problems for me, but still... My example was for a very basic usage. But what if you want to say do multi-inserts, AND commit on every inserts so that if one insert fails, the others still go through, and you can get a list of failed ones? I've had this case! And this class can handle this, without writing too much code. I am not going to debate 'why' I think my class is useful here... Before saying anything, have a look at its UsageExamples.php and decide for yourself. If you don't think it to be useful, then by all means, don't use it I'm not trying to sell it here , but rather just share.

Here's an example of a simple utilization of my DBWrapper: try { $mydb = new DBWrapper(); // get the data and do what you want with it... $data = $mydb->readData('SELECT * FROM users where ID = :id', $userid); ... } catch (DBWrapperException $ex) { die($ex->getMessage()); } The DBWrapper / readData() will take care of creating the PDO object, if it's not already created. It will take care of creating a proper PDOStatement inside it, use bindParam and protect against SQL injections, etc. etc. You can pass the parameter value as simple value to read and storeData() (doing so, DbWrapper will determine itself datatypes to map data to in DB), but you can also pass it an array mapping parameter value => datatype.... I'm not gonna write all of its functionality's here, but you can guys get the idea, I think. Cheers. Pat

By "rewrite", I don't mean rewriting PDO lolll ! I mean I don't like having to always do my new PDO(...) And then do my prepared statements etc... I wanted to shorten my code ! Really, just have a look at the UsageExamples.php. it says it all way better than what I could explain It's... As I said: a wrapper around PDO.