Re: [PHP] PDO Transaction
2013/3/15 Lester Caine les...@lsces.co.uk Simon Dániel wrote: Hi, I have a trouble with PDO transactions. I would like to start using transactions, but I am not familiar with it. I have got a 'There is no active transaction' exception, however, I am using beginTransaction method, and also I have set PDO::ATTR_AUTOCOMMIT to false right after connecting to the database. In my whole code I have used the commit method only once. Between beginTransaction and commit methods, as far as I know, I did not use anything that could activate auto-commit. In my test code, there is only an exec method of PDO, and an execute of PDOStatement. Maybe one of these activated auto-commit? And what are the possible commands which are able to activate auto-commit? I know that the commit method can do that, but - as I already wrote - I have issued it only once, and it is in the destructor of a singleton class. So what could be the problem? You don't say which database you are trying to access. Not all actually support transactions, and some need a connection correctly set. I am using MySQL.
Re: [PHP] PDO Transaction
Simon Dániel wrote: 2013/3/15 Lester Caine les...@lsces.co.uk Simon Dániel wrote: Hi, I have a trouble with PDO transactions. I would like to start using transactions, but I am not familiar with it. I have got a 'There is no active transaction' exception, however, I am using beginTransaction method, and also I have set PDO::ATTR_AUTOCOMMIT to false right after connecting to the database. In my whole code I have used the commit method only once. Between beginTransaction and commit methods, as far as I know, I did not use anything that could activate auto-commit. In my test code, there is only an exec method of PDO, and an execute of PDOStatement. Maybe one of these activated auto-commit? And what are the possible commands which are able to activate auto-commit? I know that the commit method can do that, but - as I already wrote - I have issued it only once, and it is in the destructor of a singleton class. So what could be the problem? You don't say which database you are trying to access. Not all actually support transactions, and some need a connection correctly set. I am using MySQL. Have you read the warning on http://php.net/manual/en/ref.pdo-mysql.php? It would be of more use if it actually identified what works and what does not :( I think you need to be running in the InnoDB engine to get transactions? MyISAM will throw errors on transactions. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO Transaction
Hi, I have a trouble with PDO transactions. I would like to start using transactions, but I am not familiar with it. I have got a 'There is no active transaction' exception, however, I am using beginTransaction method, and also I have set PDO::ATTR_AUTOCOMMIT to false right after connecting to the database. In my whole code I have used the commit method only once. Between beginTransaction and commit methods, as far as I know, I did not use anything that could activate auto-commit. In my test code, there is only an exec method of PDO, and an execute of PDOStatement. Maybe one of these activated auto-commit? And what are the possible commands which are able to activate auto-commit? I know that the commit method can do that, but - as I already wrote - I have issued it only once, and it is in the destructor of a singleton class. So what could be the problem?
Re: [PHP] PDO Transaction
Simon Dániel wrote: Hi, I have a trouble with PDO transactions. I would like to start using transactions, but I am not familiar with it. I have got a 'There is no active transaction' exception, however, I am using beginTransaction method, and also I have set PDO::ATTR_AUTOCOMMIT to false right after connecting to the database. In my whole code I have used the commit method only once. Between beginTransaction and commit methods, as far as I know, I did not use anything that could activate auto-commit. In my test code, there is only an exec method of PDO, and an execute of PDOStatement. Maybe one of these activated auto-commit? And what are the possible commands which are able to activate auto-commit? I know that the commit method can do that, but - as I already wrote - I have issued it only once, and it is in the destructor of a singleton class. So what could be the problem? You don't say which database you are trying to access. Not all actually support transactions, and some need a connection correctly set. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PDO question
-Original Message- From: Jim Lucas [mailto:li...@cmsws.com] Sent: Wednesday, November 28, 2012 9:23 PM To: ad...@buskirkgraphics.com Cc: php-general@lists.php.net Subject: Re: [PHP] PDO question On 11/28/2012 12:58 PM, ad...@buskirkgraphics.com wrote: Guys, I am not quiet sure what is happening but every time i try to connect to a remote host it refers back to localhost. $pdo = new PDO('mysql:host=171.16.23.44;dbname=test', 'user','password'); ERROR: Access denied for user 'user'@'localhost' (using password: YES) in /var/www/html/text.php Any clue as to WHY it keeps referring back to localhost when i clearly set the host parameter to another server. I checked the /etc/hosts records to see if there was a referral for that domain back to it's self there is NOT. There is a warning on the following page that talks about a possible issue with connections. Might give it a look. http://www.php.net/manual/en/ref.pdo-mysql.connection.php -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ Thank you issue resolved for some reason it was passing the credentials with the fully qualified domain name and NOT the IP and the permission failed to match. Not sure why it is suddenly passing the fully qualified domain name now but as long and this works I really don’t care thanks. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO question
Guys, I am not quiet sure what is happening but every time i try to connect to a remote host it refers back to localhost. $pdo = new PDO('mysql:host=171.16.23.44;dbname=test', 'user','password'); ERROR: Access denied for user 'user'@'localhost' (using password: YES) in /var/www/html/text.php Any clue as to WHY it keeps referring back to localhost when i clearly set the host parameter to another server. I checked the /etc/hosts records to see if there was a referral for that domain back to it's self there is NOT.
[PHP] PDO mysql Connection issue
I am having a PDO mysql connection issue I cant explain. On server server1.mydomain.com I have a test script ?php $pdo = new PDO('mysql:host=171.16.23.44;dbname=test', 'user','password'); ? 171.16.23.44 is by an A record called server2.mydoamin.com they are 2 different servers. This script returns an error: ERROR: Access denied for user 'user'@'server1.mydomain.com' (using password: YES) I find this ODD because that is not the server i am connecting TO but FROM. Why would the PDO connection be referring back to its own localhost instead of the intended domain. I have tried this by fully qualified domain name, same thing. I have ensured the route does exist on the connecting server. I have ensured there is no local reference to the domain name/IP back to its self. I log into 171.16.23.44 and there is NO record of the failed attempt. I validate the user has remote access rights. I validate there is not a firewall rule blocking the host/port/you name it. I telnet from the server to the destination via port 3306 it connects. BTW (171.16.23.44) IS FAKE I AM USING THE IP AS AN EXAMPLE HERE. Any clue as to WHY the host parameter is not setting or is it setting and something else is wrong?
Re: [PHP] PDO mysql Connection issue
On Wednesday, November 28, 2012 at 4:50 PM, ad...@buskirkgraphics.com wrote: I am having a PDO mysql connection issue I cant explain. On server server1.mydomain.com (http://server1.mydomain.com) I have a test script ?php $pdo = new PDO('mysql:host=171.16.23.44;dbname=test', 'user','password'); ? 171.16.23.44 is by an A record called server2.mydoamin.com (http://server2.mydoamin.com) they are 2 different servers. This script returns an error: ERROR: Access denied for user 'user'@'server1.mydomain.com (http://server1.mydomain.com)' (using password: YES) I find this ODD because that is not the server i am connecting TO but FROM. Why would the PDO connection be referring back to its own localhost instead of the intended domain. I have tried this by fully qualified domain name, same thing. I have ensured the route does exist on the connecting server. I have ensured there is no local reference to the domain name/IP back to its self. I log into 171.16.23.44 and there is NO record of the failed attempt. I validate the user has remote access rights. I validate there is not a firewall rule blocking the host/port/you name it. I telnet from the server to the destination via port 3306 it connects. BTW (171.16.23.44) IS FAKE I AM USING THE IP AS AN EXAMPLE HERE. Any clue as to WHY the host parameter is not setting or is it setting and something else is wrong? Have you tried running FLUSH HOSTS on the MySQL server? Also, i would try to disable DNS within MYSQL by starting with --skip-name-resolve (http://dev.mysql.com/doc/refman/5.0/en/server-options.html#option_mysqld_skip-name-resolve); -- Mike Mackintosh PHP 5.3 ZCE
Re: [PHP] PDO mysql Connection issue
On Wednesday, November 28, 2012 at 4:50 PM, ad...@buskirkgraphics.com wrote: I am having a PDO mysql connection issue I cant explain. On server server1.mydomain.com (http://server1.mydomain.com) I have a test script ?php $pdo = new PDO('mysql:host=171.16.23.44;dbname=test', 'user','password'); ? 171.16.23.44 is by an A record called server2.mydoamin.com (http://server2.mydoamin.com) they are 2 different servers. This script returns an error: ERROR: Access denied for user 'user'@'server1.mydomain.com (http://server1.mydomain.com)' (using password: YES) I find this ODD because that is not the server i am connecting TO but FROM. Why would the PDO connection be referring back to its own localhost instead of the intended domain. I have tried this by fully qualified domain name, same thing. I have ensured the route does exist on the connecting server. I have ensured there is no local reference to the domain name/IP back to its self. I log into 171.16.23.44 and there is NO record of the failed attempt. I validate the user has remote access rights. I validate there is not a firewall rule blocking the host/port/you name it. I telnet from the server to the destination via port 3306 it connects. BTW (171.16.23.44) IS FAKE I AM USING THE IP AS AN EXAMPLE HERE. Any clue as to WHY the host parameter is not setting or is it setting and something else is wrong? Have you tried running FLUSH HOSTS on the MySQL server? Also, i would try to disable DNS within MYSQL by starting with --skip-name-resolve (http://dev.mysql.com/doc/refman/5.0/en/server-options.html#option_mysqld_skip-name-resolve); -- Mike Mackintosh PHP 5.3 ZCE I have tried the options listed same results. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO question
On 11/28/2012 12:58 PM, ad...@buskirkgraphics.com wrote: Guys, I am not quiet sure what is happening but every time i try to connect to a remote host it refers back to localhost. $pdo = new PDO('mysql:host=171.16.23.44;dbname=test', 'user','password'); ERROR: Access denied for user 'user'@'localhost' (using password: YES) in /var/www/html/text.php Any clue as to WHY it keeps referring back to localhost when i clearly set the host parameter to another server. I checked the /etc/hosts records to see if there was a referral for that domain back to it's self there is NOT. There is a warning on the following page that talks about a possible issue with connections. Might give it a look. http://www.php.net/manual/en/ref.pdo-mysql.connection.php -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO question
On Wed, Nov 28, 2012 at 9:22 PM, Jim Lucas li...@cmsws.com wrote: On 11/28/2012 12:58 PM, ad...@buskirkgraphics.com wrote: Guys, I am not quiet sure what is happening but every time i try to connect to a remote host it refers back to localhost. $pdo = new PDO('mysql:host=171.16.23.44;**dbname=test', 'user','password'); ERROR: Access denied for user 'user'@'localhost' (using password: YES) in /var/www/html/text.php Any clue as to WHY it keeps referring back to localhost when i clearly set the host parameter to another server. I checked the /etc/hosts records to see if there was a referral for that domain back to it's self there is NOT. There is a warning on the following page that talks about a possible issue with connections. Might give it a look. http://www.php.net/manual/en/**ref.pdo-mysql.connection.phphttp://www.php.net/manual/en/ref.pdo-mysql.connection.php -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php specify a user from your IP ( not the server IP: 171.16.23.44 ) and try again.. If u dont have static IP, set host parameter for user: % means any host. and connect.
[PHP] PDO
Hello, i have built php 5.4.7 on Ubuntu with the configure Arguments like on my Gentoo System. But on Gentoo run the website without Problems, under Ubuntu want not work. I become in error.log: [22-Oct-2012 21:15:00 UTC] PHP Fatal error: Call to a member function prepare() on a non-object in html/index.html on line 23 U use PHP FPM with Nginx. The configure Arguments: http://pastebin.geany.org/qz8TP/ The Script which work: ?php require_once (db.php); $query = $db-prepare(SELECT id, title, date FROM bloggen ORDER BY date DESC LIMIT 0,5); if (!$query) {die(Execute query error, because: . $db-errorInfo());} $query-execute(); while ($row = $query-fetch(PDO::FETCH_ASSOC)) { echo pa href=\/blog/post.html?id=.$row['id'].\ title=\.(htmlentities($row['title'], ENT_QUOTES, UTF-8)).\.(htmlentities($row['title'], ENT_QUOTES, UTF-8))./a/p\n; } $row = null; $query = null; $db = null; ? Has someone a idea what is there wrong? Thanks for help and nice Day. Silvio -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO
On Mon, Oct 22, 2012 at 3:27 PM, Silvio Siefke siefke_lis...@web.de wrote: Hello, i have built php 5.4.7 on Ubuntu with the configure Arguments like on my Gentoo System. But on Gentoo run the website without Problems, under Ubuntu want not work. I become in error.log: [22-Oct-2012 21:15:00 UTC] PHP Fatal error: Call to a member function prepare() on a non-object in html/index.html on line 23 U use PHP FPM with Nginx. The configure Arguments: http://pastebin.geany.org/qz8TP/ The Script which work: ?php require_once (db.php); $query = $db-prepare(SELECT id, title, date FROM bloggen ORDER BY date DESC LIMIT 0,5); if (!$query) {die(Execute query error, because: . $db-errorInfo());} That looks like you've not connected to the database successfully inside of db.php. -nathan
Re: [PHP] PDO
On Mon, 2012-10-22 at 23:27 +0200, Silvio Siefke wrote: Hello, i have built php 5.4.7 on Ubuntu with the configure Arguments like on my Gentoo System. But on Gentoo run the website without Problems, under Ubuntu want not work. I become in error.log: [22-Oct-2012 21:15:00 UTC] PHP Fatal error: Call to a member function prepare() on a non-object in html/index.html on line 23 U use PHP FPM with Nginx. The configure Arguments: http://pastebin.geany.org/qz8TP/ The Script which work: ?php require_once (db.php); $query = $db-prepare(SELECT id, title, date FROM bloggen ORDER BY date DESC LIMIT 0,5); if (!$query) {die(Execute query error, because: . $db-errorInfo());} $query-execute(); while ($row = $query-fetch(PDO::FETCH_ASSOC)) { echo pa href=\/blog/post.html?id=.$row['id'].\ title=\.(htmlentities($row['title'], ENT_QUOTES, UTF-8)).\.(htmlentities($row['title'], ENT_QUOTES, UTF-8))./a/p\n; } $row = null; $query = null; $db = null; ? Has someone a idea what is there wrong? Thanks for help and nice Day. Silvio It's a bit odd that you're parsing all .html files as if they were PHP (little bit of a waste, and does mean you'll have an extra step when configuring a server to run the code) That aside, I don't see 23 lines of code in your example, so I'm assuming you've snipped a lot of the beginning (you've not mentioned in particular which line in your excerpt is the 23rd). What's in your db.php include? Are there any checks on whether a connection has been established or not there? -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] PDO
On Mon, Oct 22, 2012 at 5:27 PM, Silvio Siefke siefke_lis...@web.de wrote: Hello, i have built php 5.4.7 on Ubuntu with the configure Arguments like on my Gentoo System. But on Gentoo run the website without Problems, under Ubuntu want not work. I become in error.log: [22-Oct-2012 21:15:00 UTC] PHP Fatal error: Call to a member function prepare() on a non-object in html/index.html on line 23 Can you show the code in db.php (just remember to remove any login credentials)? It looks like there's an issue creating the $db object you're using. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO
Hello, i found the mistake, i have forgetten write the new path for the sqlite database. Thx Silvio -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO
Silvio Siefke wrote: i found the mistake, i have forgetten write the new path for the sqlite database. Just been caught with a similar problem. Had moved a working site from windows to linux and it stopped serving up the swf files. Turns out the file has a hardcoded path with upper and lower case name, while the xml file was all lower case. Rename the folder with the right cases and it started working again :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: extend or encapsulate?
From OOP point of view. Use encapsulation: When a class has a has-a relation-ship with other class you should use encapsulation. For example, If MyDB is a class that has-a pdo driver in it, then PDO will be encapsulated inside MyDB class. This is also called containment. MyDB should contain PDO. Use inheritance: When a class has a is-a relation ship with other class use inheritance. For example, Dog is an Animal. so Dog should extend Animal class. MyPHPDb is-a PHP Database Object (aka PDO). So it'll be inheritance. MyPHPDb should extend PDO. Think about the relation have. Then implement it. -- Shiplu.Mokadd.im ImgSign.com | A dynamic signature machine Innovation distinguishes between follower and leader
Re: [PHP] PDO: extend or encapsulate?
On Sun, Jul 15, 2012 at 5:50 AM, shiplu shiplu@gmail.com wrote: From OOP point of view. Use encapsulation: When a class has a has-a relation-ship with other class you should use encapsulation. For example, If MyDB is a class that has-a pdo driver in it, then PDO will be encapsulated inside MyDB class. This is also called containment. MyDB should contain PDO. Use inheritance: When a class has a is-a relation ship with other class use inheritance. For example, Dog is an Animal. so Dog should extend Animal class. MyPHPDb is-a PHP Database Object (aka PDO). So it'll be inheritance. MyPHPDb should extend PDO. Think about the relation have. Then implement it. -- Shiplu.Mokadd.im ImgSign.com | A dynamic signature machine Innovation distinguishes between follower and leader Yes, good: has-a and is-a. In some cases, the distinction seems clear. The think in this case, the class I'm implementing has-a PDO driver, rather than is-a PDO driver. In this case, I'm encapsulting the PDO classes within my class to provide removal of details from the main program for dealing with data, which isn't particularly interested in how that data is manipulated or stored. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: extend or encapsulate?
On Sat, Jul 14, 2012 at 12:04 AM, Paul M Foster pa...@quillandmouse.com wrote: On Fri, Jul 13, 2012 at 12:06:22AM -0500, tamouse mailing lists wrote: It's Friday, so... Yes, it's true, I have just started looking at using PDO instead of mysqli -- a bit behind the times... My question at this stage, is do people tend to extend the PDO class for their own use, or encapsulate it in a class (or do most people use it mostly in procedural code?) I encapsulated it in my own database class. One reason for that is that the PDO class is really two classes, which is fine for low level drivers but not production code that I have to use daily. A second reason is that many of the methods are not really necessary in a production environment. I want to limit the methods my code uses to interact with the database. Third, I wanted to handle errors and exceptions with my own methods, more suitable to the code I write. For example, a fatal error should only, but always, be issued if the database code is given something illegal to chew on. Anything else, like a failure to return the expected result, should simply yield some sort of sentinal value or something. If *my code* ever gives the database library something illegal to chew on, then it should only be because of my bad code, not because a user managed to somehow get bad data through. That is, my code should always catch illegal data before it ever gets to the database library. Fourth, encapsulation means that I can have the class itself carry around some of the data that I would normally have to explicitly pass around among functions. This way, I make that useful data (like the number of records returned from the last fetch), part of the payload of the class itself. Extension is tricky and requires a more subtle and refined knowledge of the classes involved. Besides, it exposes methods which I would prefer not be used by my code. Encapsulation limits the methods of the classes to just what I deem necessary and no more. I can always write new methods if I need them. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com I am rather agreeing with both of you. Back in the days I used to poke at Java, one of the caveats was to only inherit from abstract classes, and encapsulate final classes. It does make more sense to me that way. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: extend or encapsulate?
wrote in message news:1535031289.371987.1342162338279.javamail.open-xcha...@email.1und1.de... tamouse mailing lists tamouse.li...@gmail.com hat am 13. Juli 2012 um 07:06 geschrieben: It's Friday, so... Yes, it's true, I have just started looking at using PDO instead of mysqli -- a bit behind the times... My question at this stage, is do people tend to extend the PDO class for their own use, or encapsulate it in a class (or do most people use it mostly in procedural code?) I stick to use it as components as it is said Do not use inheritance for code re-use :) The idea that you shouldn't use inheritance for code reuse is absolute nonsense as it makes a mockery of one of the fundamental principles of object oriented programming. If you make a mess of inheritance it's because your implementation is flawed, not that the concept is flawed. Next you'll be saying don't use encapsulationor don't use polymorphism. What a bunch of idiots! -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: extend or encapsulate?
tamouse mailing lists wrote: I am rather agreeing with both of you. Back in the days I used to poke at Java, one of the caveats was to only inherit from abstract classes, and encapsulate final classes. It does make more sense to me that way. One option is to keep both drivers available ... ADOdb will use either the generic or PDO which is useful when PDO does not provide access to key database specific functions. I've been testing the PDO driver on my own code simply by switching which one is loaded, but I still find the generic driver for Firebird is faster - when wrapped in ADOdb. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: extend or encapsulate?
Am 14.07.12 10:09, schrieb Tony Marston: wrote in message news:1535031289.371987.1342162338279.javamail.open-xcha...@email.1und1.de... tamouse mailing lists tamouse.li...@gmail.com hat am 13. Juli 2012 um 07:06 geschrieben: It's Friday, so... Yes, it's true, I have just started looking at using PDO instead of mysqli -- a bit behind the times... My question at this stage, is do people tend to extend the PDO class for their own use, or encapsulate it in a class (or do most people use it mostly in procedural code?) I stick to use it as components as it is said Do not use inheritance for code re-use :) The idea that you shouldn't use inheritance for code reuse is absolute nonsense as it makes a mockery of one of the fundamental principles of object oriented programming. If you make a mess of inheritance it's because your implementation is flawed, not that the concept is flawed. Next you'll be saying don't use encapsulationor don't use polymorphism. What a bunch of idiots! No, I disagree with you. Don't use inheritance for code re-use, use it for class extension! If you have a class and want to add something extra to it but what does stays in the same topic, then extend from it. If you simply extend PDO to use the PDO methods and add your own stuff, then inheritance is a bad idea. If you think of what you are doing here: You USE Pdo. So it is a component. This way you get the following benefits: - You can extend your class in your system from another class AND use PDO - You can easily exchange PDO with another abstraction layer if you like, without changing the interface, just changing the implmentation -- Marco Behnke Dipl. Informatiker (FH), SAE Audio Engineer Diploma Zend Certified Engineer PHP 5.3 Tel.: 0174 / 9722336 e-Mail: ma...@behnke.biz Softwaretechnik Behnke Heinrich-Heine-Str. 7D 21218 Seevetal http://www.behnke.biz signature.asc Description: OpenPGP digital signature
Re: [PHP] PDO: extend or encapsulate?
tamouse mailing lists tamouse.li...@gmail.com hat am 13. Juli 2012 um 07:06 geschrieben: It's Friday, so... Yes, it's true, I have just started looking at using PDO instead of mysqli -- a bit behind the times... My question at this stage, is do people tend to extend the PDO class for their own use, or encapsulate it in a class (or do most people use it mostly in procedural code?) I stick to use it as components as it is said Do not use inheritance for code re-use :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Marco Behnke Dipl. Informatiker (FH), SAE Audio Engineer Diploma Zend Certified Engineer PHP 5.3 Tel.: 0174 / 9722336 e-Mail: ma...@behnke.biz Softwaretechnik Behnke Heinrich-Heine-Str. 7D 21218 Seevetal http://www.behnke.biz -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: extend or encapsulate?
On Fri, Jul 13, 2012 at 12:06:22AM -0500, tamouse mailing lists wrote: It's Friday, so... Yes, it's true, I have just started looking at using PDO instead of mysqli -- a bit behind the times... My question at this stage, is do people tend to extend the PDO class for their own use, or encapsulate it in a class (or do most people use it mostly in procedural code?) I encapsulated it in my own database class. One reason for that is that the PDO class is really two classes, which is fine for low level drivers but not production code that I have to use daily. A second reason is that many of the methods are not really necessary in a production environment. I want to limit the methods my code uses to interact with the database. Third, I wanted to handle errors and exceptions with my own methods, more suitable to the code I write. For example, a fatal error should only, but always, be issued if the database code is given something illegal to chew on. Anything else, like a failure to return the expected result, should simply yield some sort of sentinal value or something. If *my code* ever gives the database library something illegal to chew on, then it should only be because of my bad code, not because a user managed to somehow get bad data through. That is, my code should always catch illegal data before it ever gets to the database library. Fourth, encapsulation means that I can have the class itself carry around some of the data that I would normally have to explicitly pass around among functions. This way, I make that useful data (like the number of records returned from the last fetch), part of the payload of the class itself. Extension is tricky and requires a more subtle and refined knowledge of the classes involved. Besides, it exposes methods which I would prefer not be used by my code. Encapsulation limits the methods of the classes to just what I deem necessary and no more. I can always write new methods if I need them. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO: extend or encapsulate?
It's Friday, so... Yes, it's true, I have just started looking at using PDO instead of mysqli -- a bit behind the times... My question at this stage, is do people tend to extend the PDO class for their own use, or encapsulate it in a class (or do most people use it mostly in procedural code?) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prevent duplicate field names?
On Mon, Jul 2, 2012 at 5:38 PM, Scott Baker bak...@canbytel.com wrote: It was my mistake, and the SQL was easily fixed. But it woulda been nice to have PHP realize there was a dupe when it was building that array to return to me. This is just not a province of PHP. What sort of behaviour would one expect PHP to do given this scenario? It is surely not an error in every case; I can see some code relying on this exact behaviour. Making it some sort of option in PHP increases the complexity a great deal, not only in trying to determine how to design and then *change* the API to accommodate it, but in figuring out what exactly one might *do*. Since SQL is a completely separate language from PHP, it makes much more sense to learn to deal with these thing separately, and understand what your SQL is doing. Indeed, SQL will happily return multiple columns with the same column name; you must be aware of this when writing it. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO Prevent duplicate field names?
$sql = SELECT First, Last, Age, 'Foobar' AS Last;; This is a simplified example of a SQL query where we're returning two fields with the same name (Last). When I do a fetch_assoc with this query I only get three fields, as the second Last field over writes the first one. I was hoping there was some method with PDO that would detect that and throw a warning. Maybe some sort of strict mode that would tell me I'm doing something stupid. Is there a way to catch this before it bites me? It already bit me, but moving forward it'd be nice if PHP saw that before I spent an hour debugging it again. - Scott -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prevent duplicate field names?
On Tue, Jul 3, 2012 at 12:25 AM, Scott Baker bak...@canbytel.com wrote: $sql = SELECT First, Last, Age, 'Foobar' AS Last;; This is a simplified example of a SQL query where we're returning two fields with the same name (Last). When I do a fetch_assoc with this query I only get three fields, as the second Last field over writes the first one. I was hoping there was some method with PDO that would detect that and throw a warning. Maybe some sort of strict mode that would tell me I'm doing something stupid. Is there a way to catch this before it bites me? It already bit me, but moving forward it'd be nice if PHP saw that before I spent an hour debugging it again. - Scott Why the would you want to return 2 columns with the same name? To be short, there's no such function, so you have to: 1) Rename one of the columns 2) or, use fetch_row with numerical indexes instead of fetch_assoc. - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prevent duplicate field names?
On 07/02/2012 03:34 PM, Matijn Woudt wrote: Why the would you want to return 2 columns with the same name? To be short, there's no such function, so you have to: 1) Rename one of the columns 2) or, use fetch_row with numerical indexes instead of fetch_assoc. My real world scenario was this SELECT a.CustID, b.* FROM Customer a LEFT JOIN Sales B USING (CustID) WHERE a.CustID = 1234; In that case, there was a record in Customer, but not in Sales. Sales returned CustID as NULL, which overwrote the one from Customer. It was my mistake, and the SQL was easily fixed. But it woulda been nice to have PHP realize there was a dupe when it was building that array to return to me. -- Scott Baker - Canby Telcom System Administrator - RHCE - 503.266.8253 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prevent duplicate field names?
On Tue, Jul 3, 2012 at 12:38 AM, Scott Baker bak...@canbytel.com wrote: On 07/02/2012 03:34 PM, Matijn Woudt wrote: Why the would you want to return 2 columns with the same name? To be short, there's no such function, so you have to: 1) Rename one of the columns 2) or, use fetch_row with numerical indexes instead of fetch_assoc. My real world scenario was this SELECT a.CustID, b.* FROM Customer a LEFT JOIN Sales B USING (CustID) WHERE a.CustID = 1234; In that case, there was a record in Customer, but not in Sales. Sales returned CustID as NULL, which overwrote the one from Customer. It was my mistake, and the SQL was easily fixed. But it woulda been nice to have PHP realize there was a dupe when it was building that array to return to me. Which makes me wonder, why are you returning a.CustID, if b includes CustID too and a.CustID == b.CustID? As to why there are no checks,.. I guess it's just that it's not a common error. And after all, all it does is set a value in an array twice, that doesn't result in warnings elsewhere (thank god ;)) - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prevent duplicate field names?
On 07/02/2012 03:38 PM, Scott Baker wrote: On 07/02/2012 03:34 PM, Matijn Woudt wrote: Why the would you want to return 2 columns with the same name? To be short, there's no such function, so you have to: 1) Rename one of the columns 2) or, use fetch_row with numerical indexes instead of fetch_assoc. My real world scenario was this SELECT a.CustID, b.* FROM Customer a LEFT JOIN Sales B USING (CustID) WHERE a.CustID = 1234; In that case, there was a record in Customer, but not in Sales. Sales returned CustID as NULL, which overwrote the one from Customer. It was my mistake, and the SQL was easily fixed. But it woulda been nice to have PHP realize there was a dupe when it was building that array to return to me. You could always do this. SELECT b.*, a.CustID FROM Customer a LEFT JOIN Sales B USING (CustID) WHERE a.CustID = 1234; -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP, PDO and MS-SQL ?
Hi, could someone tell me what I need to install and how to configure everything so that I can connect with PHP and PDO to a MS-SQL server? I have an OpenSuse 11.4 installation. I added the Apache-PHP repository and upgraded to PHP 5.3.8. php-mssql, -php-odbc, libfreetds and the freetds-tools are installed. Do I need all this or anything else? phpinfos() reports the odbc and mssql modules are loaded. I can't find config files, though. The aim is to connect to a ms-sql server using PDO without a system dsn if possible. Is there a detailed description for people who don't know everything about this stuff, yet? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prepared Statements and stripslashes
On Mon, Dec 20, 2010 at 11:31 PM, Rico Secada coolz...@it.dk wrote: Hi. In an article about SQL Injection by Chris Shiflett he mentions the following in a comment: The process of escaping should preserve data, so it should never be necessary to reverse it. When I'm auditing an application, things like stripslashes() alert me to design problems. Adding slashes to variables isn't needed for actually storing the values in the DB, but rather for their safe use in a SQL statement. If you use addslashes() on data going into a DB, you'll have to make sure you call stripslashes() on data coming out of the DB. His statement The process of escaping should preserve data, so it should never be necessary to reverse it, conveys that you shouldn't need to know if a value has been escaped down the line. The escaping operation should be done in such a way that it doesn't matter how you handle the data afterwards (your code shouldn't have to keep track of whether it has to call stripslashes(), with one notable problem being that calling stripslashes() twice on the same data can lead to a value that differs from the original.) Now, I'm always using PHP PDO with prepared statements and as such data with quotes gets slashed automatically by PDO when inserted into the database. In most languages I'm familiar with, prepared statements don't imply that values are automatically slashed. Rather, the statement is compiled with placeholders. Through use of placeholders, it's impossible for the DB to interpret any of the values inserted into any of the placeholders in a way that could lead to SQL injection. When I need to pull out the data something might be slashed and I need to use stripslashes() or some str_replace() to make sure that the slashes are removed. NO, using prepared statements does not require that you call stripslashes() when retrieving data from the DB. If you're noticing slashes, you've got them coming from other source (magic_quotes_gpc might be on, and if so, I recommend turning it off.) So what's the mistake here and what's the correct way to do it? 1. Turn off magic_quotes_gpc if on, as its use has been deprecated. 2. Use prepared statements. 3. Don't worry about stripping slashes ever again :) Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] PDO Prepared Statements and stripslashes
On Tue, 21 Dec 2010 10:32:21 -0500 Adam Richardson simples...@gmail.com wrote: 1. Turn off magic_quotes_gpc if on, as its use has been deprecated. 2. Use prepared statements. 3. Don't worry about stripping slashes ever again :) Thank you for a very enlightening answer. I guess I misunderstood the PDO automatically quotes.. and the slashes part! :-) Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO Prepared Statements and stripslashes
Hi. In an article about SQL Injection by Chris Shiflett he mentions the following in a comment: The process of escaping should preserve data, so it should never be necessary to reverse it. When I'm auditing an application, things like stripslashes() alert me to design problems. Now, I'm always using PHP PDO with prepared statements and as such data with quotes gets slashed automatically by PDO when inserted into the database. When I need to pull out the data something might be slashed and I need to use stripslashes() or some str_replace() to make sure that the slashes are removed. So what's the mistake here and what's the correct way to do it? Kind regards Rico -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prepared Statements and stripslashes
On Tue, Dec 21, 2010 at 05:31:15AM +0100, Rico Secada wrote: Hi. In an article about SQL Injection by Chris Shiflett he mentions the following in a comment: The process of escaping should preserve data, so it should never be necessary to reverse it. When I'm auditing an application, things like stripslashes() alert me to design problems. Now, I'm always using PHP PDO with prepared statements and as such data with quotes gets slashed automatically by PDO when inserted into the database. Just out of idle curiosity, are you using MySQL? PDO shouldn't be backslashing quotes for PostgreSQL, as the PostgreSQL convention for values containing single quotes is to double the quotes, as: ''. When I need to pull out the data something might be slashed and I need to use stripslashes() or some str_replace() to make sure that the slashes are removed. So what's the mistake here and what's the correct way to do it? I don't see a mistake. If the values come out of the database backslashed, then you need to remove them to work with the data. My only question would be whether you're sure the data is backslashed before PDO ever sees it. In which case, yes, you have a problem. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prepared Statements and stripslashes
On Tue, 21 Dec 2010 00:32:19 -0500 Paul M Foster pa...@quillandmouse.com wrote: On Tue, Dec 21, 2010 at 05:31:15AM +0100, Rico Secada wrote: Hi. In an article about SQL Injection by Chris Shiflett he mentions the following in a comment: The process of escaping should preserve data, so it should never be necessary to reverse it. When I'm auditing an application, things like stripslashes() alert me to design problems. Now, I'm always using PHP PDO with prepared statements and as such data with quotes gets slashed automatically by PDO when inserted into the database. Just out of idle curiosity, are you using MySQL? PDO shouldn't be backslashing quotes for PostgreSQL, as the PostgreSQL convention for values containing single quotes is to double the quotes, as: ''. Currently I'm working with MySQL, but I have just tested PDO with PostgreSQL 8.3 and in this case PDO backslashes PostgreSQL as well. When I need to pull out the data something might be slashed and I need to use stripslashes() or some str_replace() to make sure that the slashes are removed. So what's the mistake here and what's the correct way to do it? I don't see a mistake. If the values come out of the database backslashed, then you need to remove them to work with the data. My only question would be whether you're sure the data is backslashed before PDO ever sees it. In which case, yes, you have a problem. No, the data is not slashed before PDO sees them. I didn't see a mistake either, but then what does Chris mean? Stripping slashes from output from the DB alerts him to a design problem, and I'm just wondering if there another way of doing things I just haven't heard of then. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Prepared Statements and stripslashes
Hello, The plug-in PDO has nothing to do with the backslashes being inserted into the database. The backslashes are used to escape characters like in D's...it would show D's. That's the safe behavior of it. You can change your programming code to fix that. Ravi. On Tue, Dec 21, 2010 at 12:59 AM, Rico Secada coolz...@it.dk wrote: On Tue, 21 Dec 2010 00:32:19 -0500 Paul M Foster pa...@quillandmouse.com wrote: On Tue, Dec 21, 2010 at 05:31:15AM +0100, Rico Secada wrote: Hi. In an article about SQL Injection by Chris Shiflett he mentions the following in a comment: The process of escaping should preserve data, so it should never be necessary to reverse it. When I'm auditing an application, things like stripslashes() alert me to design problems. Now, I'm always using PHP PDO with prepared statements and as such data with quotes gets slashed automatically by PDO when inserted into the database. Just out of idle curiosity, are you using MySQL? PDO shouldn't be backslashing quotes for PostgreSQL, as the PostgreSQL convention for values containing single quotes is to double the quotes, as: ''. Currently I'm working with MySQL, but I have just tested PDO with PostgreSQL 8.3 and in this case PDO backslashes PostgreSQL as well. When I need to pull out the data something might be slashed and I need to use stripslashes() or some str_replace() to make sure that the slashes are removed. So what's the mistake here and what's the correct way to do it? I don't see a mistake. If the values come out of the database backslashed, then you need to remove them to work with the data. My only question would be whether you're sure the data is backslashed before PDO ever sees it. In which case, yes, you have a problem. No, the data is not slashed before PDO sees them. I didn't see a mistake either, but then what does Chris mean? Stripping slashes from output from the DB alerts him to a design problem, and I'm just wondering if there another way of doing things I just haven't heard of then. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
On Dec 14, 2010, at 5:45 PM, Govinda wrote: In previous experience with questions such as these, you will get several types of individual responses to usages of the software. Some good, some bad, depending on the experience level of the commenter with both the language and the code in question. It's a combination of your current understanding of php and the associated usages of other languages, and what you want to know. Don't trust what people say, trust what feels right at the current time of your usage of the php library available/your experience level, and what you currently know how to use. From my experience with several languages, once you know the basics, even if you do re-invent the 'wheel', so did firestone,michelin, and goodyear, and they're not complaining. And you'll feel better for reinventing, than using someone elses. I think this ^^^ advice is brilliant, understated; nothing replaces integration of one's own thorough understanding. Govinda govinda(DOT)webdnatalk(AT)gmail(DOT)com @the OP I absolutely agree. One-thousand people will miraculously come up with two-thousand opinions on PDO and similar tools. PDO is only one of many, many tools in your toolbox. At the end of the day - get ahold of PDO, mess around with it a bit, read some docs, etc.. See what you can do with it, then see if it was worth the learning curve and how you can leverage your newly found knowledge on your next project. Then, drop it like it's hot when you don't need it. No need to jam a square peg in a round hole. Whip out your pocket knife and make a round peg for a nice snug fit. After all, that's why you carry a pocket knife - right? If it feels good - do it.
[PHP] PDO: good, popular?
Searching for PHP CRUD in hopes of learning the best way to access databases and to use PEAR or what I came across PDO. I want to know the communities opinion of PDO: everyone uses it or no one uses it or it's great or what? Thanks
Re: [PHP] PDO: good, popular?
On Tue, Dec 14, 2010 at 6:10 AM, Sam Smith a...@itab.com wrote: Searching for PHP CRUD in hopes of learning the best way to access databases and to use PEAR or what I came across PDO. I want to know the communities opinion of PDO: everyone uses it or no one uses it or it's great or what? In previous experience with questions such as these, you will get several types of individual responses to usages of the software. Some good, some bad, depending on the experience level of the commenter with both the language and the code in question. It's a combination of your current understanding of php and the associated usages of other languages, and what you want to know. Don't trust what people say, trust what feels right at the current time of your usage of the php library available/your experience level, and what you currently know how to use. From my experience with several languages, once you know the basics, even if you do re-invent the 'wheel', so did firestone,michelin, and goodyear, and they're not complaining. And you'll feel better for reinventing, than using someone elses. Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
On 14 December 2010 11:10, Sam Smith a...@itab.com wrote: Searching for PHP CRUD in hopes of learning the best way to access databases and to use PEAR or what I came across PDO. I want to know the communities opinion of PDO: everyone uses it or no one uses it or it's great or what? Thanks If you are developing code for a single database and you are really, really sure you're not going to ever use another DB, then maybe PDO is an unnecessary layer. If you are developing code which has to remain compatible across multiple DBs, then PDO would, on the surface, seem like a good idea. The downside though is that PDO still requires DB specific drivers. I only work on 1 DB (MS SQL). So, I don't use PDO. From http://docs.php.net/manual/en/intro.pdo.php : PDO provides a data-access abstraction layer, which means that, regardless of which database you're using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility. Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
In other words, in ten years from now, even the advisors you get today will rethink their answers with 20/20/hindsight, and not think about your ignorance of technology, but their own. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
On 14 December 2010 15:45, David Hutto smokefl...@gmail.com wrote: From my experience with several languages, once you know the basics, even if you do re-invent the 'wheel', so did firestone,michelin, and goodyear, and they're not complaining. And you'll feel better for reinventing, than using someone elses. Strange that you should mention those tyre manufacturers. I work for a tyre remoulder. We take their dead tyres and remake them into high quality remoulds. The majority of all food delivered in the UK run on our tyres! Essentially, we are recycling. Looking to the future and all that. If you can recycle others code into new and interesting ways, then go for it. Richard. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
I'm the DB maintainer for Drupal 7, and we rebuilt our entire DB layer on top of PDO. It's a rather nice API, although as others have noted it does not abstract away SQL entirely; it abstracts the API calls you need to use to get to SQL. We then built a layer on top of that which does abstract away most database weirdness using fluent query builders. It's much lighter-weight than an ORM. I'm in the process of spinning it off as a stand-alone library because we think it's that cool, but it's not completely divorced from Drupal yet. Stay tuned. :-) But yes, PDO is nice. --Larry Garfield On 12/14/10 5:10 AM, Sam Smith wrote: Searching for PHP CRUD in hopes of learning the best way to access databases and to use PEAR or what I came across PDO. I want to know the communities opinion of PDO: everyone uses it or no one uses it or it's great or what? Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
On Tue, Dec 14, 2010 at 6:10 AM, Sam Smith a...@itab.com wrote: Searching for PHP CRUD in hopes of learning the best way to access databases and to use PEAR or what I came across PDO. I want to know the communities opinion of PDO: everyone uses it or no one uses it or it's great or what? Thanks I like working with PDO. I use a very thin set of wrapper functions to automatically grab the connection information from a config file, cause errors to be thrown as exceptions, and make sure the results are formatted as arrays. It works very well and relatively fast. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] PDO: good, popular?
la...@garfieldtech.com wrote: I'm the DB maintainer for Drupal 7, and we rebuilt our entire DB layer on top of PDO. It's a rather nice API, although as others have noted it does not abstract away SQL entirely; it abstracts the API calls you need to use to get to SQL. We then built a layer on top of that which does abstract away most database weirdness using fluent query builders. It's much lighter-weight than an ORM. I'm in the process of spinning it off as a stand-alone library because we think it's that cool, but it's not completely divorced from Drupal yet. Stay tuned. :-) Larry - how many databases does it actually work with? Having rebuilt the DB layer using PDO did you actually gain anything? Sam - The situation on database abstraction is not clear cut and a lot of tangents have been generated while the traditional approaches are still the best in many cases. As has been said ... if you only intend to use on database, then use the matching driver and work the SQL in a manor that works for you with that database. If you need a full range of databases supported, then ADOdb is STILL the best option, and will quite happily use a PDO or generic driver internally depending on your choice, but which ever you use ( and the generic ones still tend to be faster especially with the accelerator package ) the abstraction of the SQL is much more important then simply managing a few data conversions. ADOdb will build tables across the whole range of databases it supports from a single 'profile', while PDO needs a lot of help to do the same, preferring instead to have separate 'profiles' for each database each hand coded. PDO still needs a number of areas finishing before it can become a total replacement for the legacy stuff that is available such as the PEAR libraries and the likes of Drupal writing their own abstraction layer on top of it ... along with a number of other projects who are now doing the same thing ... shows that PDO is not creating the common platform it was supposed to :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
In previous experience with questions such as these, you will get several types of individual responses to usages of the software. Some good, some bad, depending on the experience level of the commenter with both the language and the code in question. It's a combination of your current understanding of php and the associated usages of other languages, and what you want to know. Don't trust what people say, trust what feels right at the current time of your usage of the php library available/your experience level, and what you currently know how to use. From my experience with several languages, once you know the basics, even if you do re-invent the 'wheel', so did firestone,michelin, and goodyear, and they're not complaining. And you'll feel better for reinventing, than using someone elses. I think this ^^^ advice is brilliant, understated; nothing replaces integration of one's own thorough understanding. Govinda govinda(DOT)webdnatalk(AT)gmail(DOT)com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
On Tue, Dec 14, 2010 at 03:10:56AM -0800, Sam Smith wrote: Searching for PHP CRUD in hopes of learning the best way to access databases and to use PEAR or what I came across PDO. I want to know the communities opinion of PDO: everyone uses it or no one uses it or it's great or what? I use PDO within a class which handles various housekeeping (error handling etc.) for everything. PDO handles all the popular RDBMSes (as far as I know). It can also sanitize queries to avoid SQL injection. Simple interface. It's also part of PHP, meaning it's well tested and solid. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
On Tuesday, December 14, 2010 1:02:33 pm Lester Caine wrote: la...@garfieldtech.com wrote: I'm the DB maintainer for Drupal 7, and we rebuilt our entire DB layer on top of PDO. It's a rather nice API, although as others have noted it does not abstract away SQL entirely; it abstracts the API calls you need to use to get to SQL. We then built a layer on top of that which does abstract away most database weirdness using fluent query builders. It's much lighter-weight than an ORM. I'm in the process of spinning it off as a stand-alone library because we think it's that cool, but it's not completely divorced from Drupal yet. Stay tuned. :-) Larry - how many databases does it actually work with? Having rebuilt the DB layer using PDO did you actually gain anything? Drupal 6 and earlier supported MySQL and, kinda sorta, Postgres, maybe. Drupal 7 ships with support for MySQL, Postgres, and SQLite out of the box and add-on modules provide support for Oracle and MS SQL, within reason. So we increased our DB support from 1.5 to 5, essentially. We also gained, as part of the rewrite, untyped prepared statements, transactions, and master/slave support (although that's nothing to do with PDO per se, just our layer on top of it). And that allowed us, in turn, to build type-safe query builders, support for MERGE queries, and all kinds of other fun stuff on top of that. PDO still needs a number of areas finishing before it can become a total replacement for the legacy stuff that is available such as the PEAR libraries and the likes of Drupal writing their own abstraction layer on top of it ... along with a number of other projects who are now doing the same thing ... shows that PDO is not creating the common platform it was supposed to :( That is, sadly, true. PDO is not a complete and perfect DB library, in part because there are few people who work on it, and fewer still who understand all of the vendor-specific issues at hand and the vendors have been very slow to lend a hand, preferring to work on proprietary APIs. It's quite unfortunate, but I still consider PDO an overall win. If anyone knows C and wants to make a name for themselves in the PHP world, PDO is looking for some heroes. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO working via Apache but not at the command line?
It's most likely because both cli and web modules are using different php.ini config files. See what the output of a phpinfo() call in both browser and command line. Thanks, Ash http://www.ashleysheridan.co.uk - Reply message - From: Scott Baker bak...@canbytel.com Date: Mon, Oct 18, 2010 21:20 Subject: [PHP] PDO working via Apache but not at the command line? To: p...@lists.php.net, php-general@lists.php.net I have the following very simple script that uses PDO/FreeTDS to connect to a mssql server. I have PHP Version 5.3.3 running on Linux under Apache. When I view this script via apache/firefox I get proper output. If I try and run this via the command line like php db_dump.php I get an error connecting to the DB: Unable to connect to Omnia: SQLSTATE[HY000] Unable to connect: Adaptive Server is unavailable or does not exist (severity 9). Does Apache call PHP differently than the cli would? Why would Apache method work find, but direct from the command line cause a problem? Do I need to call php from the cli with some other argument? -- $num || $num = 197804; $dbh = omnia_connect(); $sql = EXECUTE P_SaaS_AccountServiceFeatures_Retrieve $num; $sth = $dbh-prepare($sql); $sth-execute(); $foo = $sth-fetchAll(PDO::FETCH_ASSOC); foreach ($foo as $i) { if ($i['ItemStatus'] != 'I') { $out .= $i['Component'] . \n; } } print $out; function omnia_connect() { putenv('FREETDSCONF=/etc/freetds.conf'); $db = DB_NAME; $user = user; $pass = pass; $dsn = dblib:host=Omnia;dbname=$db; try { $dbh = new PDO($dsn, $user, $pass); } catch (PDOException $e) { echo 'Unable to connect to Omnia: ' . $e-getMessage(); exit; } return $dbh; } -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO working via Apache but not at the command line?
On 10/18/2010 02:17 PM, a...@ashleysheridan.co.uk wrote: It's most likely because both cli and web modules are using different php.ini config files. See what the output of a phpinfo() call in both browser and command line. I didn't even think about it parsing different php.ini files. Checking the output of phpinfo() I see it's calling the same php.ini (/usr/local/lib/php.ini) though. :( -- Scott Baker - Canby Telcom System Administrator - RHCE - 503.266.8253 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PDO] Re: [PHP] PDO working via Apache but not at the command line?
Things to check: - Environment: what env vars are set or not set in your Apache vs. CLI - Owner: are you running as the same user as your web server? - Do you or the web server have some kind of rc file that might impact how things run? Suggestion: Use sudo -u webserverusername -s to run a shell as your web server user, then try to run the CLI. Get the environment to match up with your webserver. If this still doesn't work, it might be something more esoteric; check to see if you have other apache modules loaded that might also use FreeTDS or ODBC and that might be messing with things. Use strace php db-dump.php to see what the CLI is up to. Use strace -p apachepid to see what the Apache version is up to (probably want to run apache -X to make this easier). --Wez. On Oct 18, 2010, at 5:26 PM, Scott Baker wrote: On 10/18/2010 02:17 PM, a...@ashleysheridan.co.uk wrote: It's most likely because both cli and web modules are using different php.ini config files. See what the output of a phpinfo() call in both browser and command line. I didn't even think about it parsing different php.ini files. Checking the output of phpinfo() I see it's calling the same php.ini (/usr/local/lib/php.ini) though. :( -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PDO] Re: [PHP] PDO working via Apache but not at the command line?
On 10/18/2010 06:27 PM, Wez Furlong wrote: Things to check: - Environment: what env vars are set or not set in your Apache vs. CLI - Owner: are you running as the same user as your web server? - Do you or the web server have some kind of rc file that might impact how things run? Wez you're a genius. When I ran it as the same user as apache it works fine. That got me thinking that it makes a log in /tmp. Checking the log it was only writable by the apache user. A little chmod later and now my script runs perfectly under apache and cli. Thanks for helping me think outside the box. I spent all day puzzled by this, you just made my night. - Scott -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PDO] Re: [PHP] PDO working via Apache but not at the command line?
Sounds like the error message SQLSTATE[HY000] Unable to connect: Adaptive Server is unavailable or does not exist (severity 9) could be more informative, but I think this is returned by FreeTDS, not PDO. On Mon, Oct 18, 2010 at 7:35 PM, Scott Baker bak...@canbytel.com wrote: On 10/18/2010 06:27 PM, Wez Furlong wrote: Things to check: - Environment: what env vars are set or not set in your Apache vs. CLI - Owner: are you running as the same user as your web server? - Do you or the web server have some kind of rc file that might impact how things run? Wez you're a genius. When I ran it as the same user as apache it works fine. That got me thinking that it makes a log in /tmp. Checking the log it was only writable by the apache user. A little chmod later and now my script runs perfectly under apache and cli. Thanks for helping me think outside the box. I spent all day puzzled by this, you just made my night. - Scott -- PDO Working Group Mailing List (http://pdo.php.net) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO and UPDATE problem
Hello I have a problem with a update using PDO. (learning atm and updating a php class to use PDO) private function updateUser($id) { $date = mktime(); $DB = Db::getInstance(); $stmt = $DB-prepare('UPDATE '. TBL_USERS .' SET date_last_action=:updateDate WHERE id=:userId'); $stmt-bindParam(:updateDate, $date); $stmt-bindParam(:userId, $id); $stmt-execute(); } It does not work. I get this : Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UPDATE mf_Users SET date_last_action='1279717039' WHERE id='1'' at line 1' in /public_html/forum/includes/classes/Auth.class.php on line *157* PDO works and is fine with my SELECT request's. Does not seam to work with this simple UPDATE. I tested the request in PHPMyAdmin and it works. (UPDATE mf_Users SET date_last_action='1279717039' WHERE id='1') Thx, Sky
Re: [PHP] PDO and UPDATE problem
On 21 July 2010 15:04, Sky Gunning sky.gunn...@gmail.com wrote: Hello I have a problem with a update using PDO. (learning atm and updating a php class to use PDO) private function updateUser($id) { $date = mktime(); $DB = Db::getInstance(); $stmt = $DB-prepare('UPDATE '. TBL_USERS .' SET date_last_action=:updateDate WHERE id=:userId'); Try without the extra quotation mark before UPDATE. Regards Peter -- hype WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO with text in BLOB's
I'm having fun with a project that has moved exclusively to PDO, and I'm now trying to restore firebird as an alternative database. The problem I am having is with text fields in firebird which are BLOB SUB_TYPE TEXT. These are essentially TEXT in other databases, and I'm used to ADOdb simply loading them with text strings what ever the database is using behind them. On PDO it would seem that these fields can only be connected to streams? How does one load a simple long string into one of these fields? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO - Nested selects allowed?
For my photography website, I have a photo gallery, and the user first sees a list of categories. They can click down to see thumbnails, and again to see individual photographs. I want to enhance this to, with the category listing, show the first thumbnail. I have a category table, a photo table and the photos and thumbnails are files. The photo table has a category_id column and a filename column. Now, I Googled a bit, and it is not clear that i) Select the categories ii) Loop through the result set iii) Within the loop select the filename will work Does the select within the loop clobber the result set of the category selection? I saw suggestions to fetch the entire result set into a PHP array, or to use |$dbh-setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true); The queries I have created are: $categoryquery = 'SELECT c.category_id, c.category_name, c.category_description, COUNT(photo_id) FROM gallery_category as c LEFT JOIN gallery_photos as p ON p.photo_category = c.category_id GROUP BY c.category_id ORDER BY c.category_order'; $catthumbquery = 'SELECT photo_filename FROM gallery_photos WHERE photo_category=:cid ORDER BY photo_order LIMIT 1'; and the PHP code I have drafted is: try { $stmt = $dbh-prepare($categoryquery); $stmt-execute(); while ($row = $stmt-fetch(PDO::FETCH_ASSOC)) { $id = $row['category_id']; $name= $row['category_name']; $description = $row['category_description']; $count = $row['COUNT(photo_id)']; $stmt2 = $dbh-prepare($catthumbquery); $stmt2-bindParam(':cid', $id, PDO::PARAM_STR); $stmt2-execute(); $result_array[] = \t\tdiv class=\categoryname\\n . \t\t\ta href=\viewgallery.php?cid= . $id . \ . $name . /a ($count)\n\t\t/div\n \t\tdiv class=\categorydescription\ . \n\t\t\t$description\n\t\t/div; } } catch (PDOException $e) { echo Building category list failed: . $e-getMessage(); } Thanks to those who can help! Stephen | -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PDO fetch_obj - question
Thanks. I will see. The script for my database was been generated so, I will doublecheck this uppercase issue... Regards, Márcio 2009/4/15 Thodoris t...@kinetix.gr Hi there, Ive made a fetch_obj and, as stated on some sites, it returns a anonymous object where the properties will have the name of our columns database. However, when I do this, I notice that instead of giving me the column names as they are typed on the DB I get them uppercase. So, when my database field is id_dog to retrieve the property properly I have to search for ID_DOG Why is this? Is this a normal behavior? Thanks a lot, Márcio I have just dumped an object using var_dump retrieved with pdo fetch object method: object(stdClass)#3 (4) { [id]= string(1) 1 [cat]= string(1) 1 [cod_sin]= string(6) 120014 [cod_uis]= string(2) 26 } and it seems quite normal to me. Try to see your table info using: describe `tablename`; To see what are your table's fields . Try to include more info about your system, php version etc in case you reply. It will help us to help you. -- Thodoris Done. No problem at all. The scripts as generated the database columns with uppercase. ;) Thanks for the info Thodoris. Regards, Marcio
Re: [PHP] PDO fetch_obj - question
Hi there, I’ve made a fetch_obj and, as stated on some sites, it returns a anonymous object where the properties will have the name of our columns database. However, when I do this, I notice that instead of giving me the column names as they are typed on the DB I get them uppercase. So, when my database field is “id_dog” to retrieve the property properly I have to search for “ID_DOG” Why is this? Is this a normal behavior? Thanks a lot, Márcio I have just dumped an object using var_dump retrieved with pdo fetch object method: object(stdClass)#3 (4) { [id]= string(1) 1 [cat]= string(1) 1 [cod_sin]= string(6) 120014 [cod_uis]= string(2) 26 } and it seems quite normal to me. Try to see your table info using: describe `tablename`; To see what are your table's fields . Try to include more info about your system, php version etc in case you reply. It will help us to help you. -- Thodoris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO fetch_obj - question
Thanks. I will see. The script for my database was been generated so, I will doublecheck this uppercase issue... Regards, Márcio 2009/4/15 Thodoris t...@kinetix.gr Hi there, I’ve made a fetch_obj and, as stated on some sites, it returns a anonymous object where the properties will have the name of our columns database. However, when I do this, I notice that instead of giving me the column names as they are typed on the DB I get them uppercase. So, when my database field is “id_dog” to retrieve the property properly I have to search for “ID_DOG” Why is this? Is this a normal behavior? Thanks a lot, Márcio I have just dumped an object using var_dump retrieved with pdo fetch object method: object(stdClass)#3 (4) { [id]= string(1) 1 [cat]= string(1) 1 [cod_sin]= string(6) 120014 [cod_uis]= string(2) 26 } and it seems quite normal to me. Try to see your table info using: describe `tablename`; To see what are your table's fields . Try to include more info about your system, php version etc in case you reply. It will help us to help you. -- Thodoris
[PHP] PDO fetch_obj - question
Hi there, Ive made a fetch_obj and, as stated on some sites, it returns a anonymous object where the properties will have the name of our columns database. However, when I do this, I notice that instead of giving me the column names as they are typed on the DB I get them uppercase. So, when my database field is id_dog to retrieve the property properly I have to search for ID_DOG Why is this? Is this a normal behavior? Thanks a lot, Márcio
Re: [PHP] PDO buffered query problem
Stewart Duncan wrote: Hi there, I'm having some serious problems with the PHP Data Object functions. I'm trying to loop through a sizeable result set (~60k rows, ~1gig) using a buffered query to avoid fetching the whole set. No matter what I do, the script just hangs on the PDO::query() - it seems the query is running unbuffered (why else would the change in result set size 'fix' the issue?). Here is my code to reproduce the problem: ?php $Database = new PDO( 'mysql:host=localhost;port=3306;dbname=mydatabase', 'root', '', array( PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION, PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = true ) ); Don't you want it the other way around? You want it unbuffered so it doesn't get retrieved in mysql, send the whole result set to php then you can use it. You want to start using it immediately - so make it unbuffered. Either way if the result set is going to be large your MySQL's memory or PHP's memory may exceed. So if you use either you may need to fine-tune PHP by increasing the per process memory (memory_limit in php.ini) or MySQL. In case you use unbuffered queries you cannot use transactions as far as I can recall. -- Thodoris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO buffered query problem
Thodoris wrote: Stewart Duncan wrote: Hi there, I'm having some serious problems with the PHP Data Object functions. I'm trying to loop through a sizeable result set (~60k rows, ~1gig) using a buffered query to avoid fetching the whole set. No matter what I do, the script just hangs on the PDO::query() - it seems the query is running unbuffered (why else would the change in result set size 'fix' the issue?). Here is my code to reproduce the problem: ?php $Database = new PDO( 'mysql:host=localhost;port=3306;dbname=mydatabase', 'root', '', array( PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION, PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = true ) ); Don't you want it the other way around? You want it unbuffered so it doesn't get retrieved in mysql, send the whole result set to php then you can use it. You want to start using it immediately - so make it unbuffered. Either way if the result set is going to be large your MySQL's memory or PHP's memory may exceed. So if you use either you may need to fine-tune PHP by increasing the per process memory (memory_limit in php.ini) or MySQL. The point of unbuffered queries is that they only take up memory while transferring a particular row's data. It won't get the whole lot from mysql, store it all in php (taking up memory for all x rows in the result set), then start working on it. So it won't take up that much memory - you'll only ever have one row of data in memory. Of course, the downside is that you can't do another query until the whole result has been processed. Personally I'd never try to work on 60k items at once, I'd chunk my results (work on 1000 items at a time) and go from there, but that of course depends on what needs to be done. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO buffered query problem
Hi there, I'm having some serious problems with the PHP Data Object functions. I'm trying to loop through a sizeable result set (~60k rows, ~1gig) using a buffered query to avoid fetching the whole set. No matter what I do, the script just hangs on the PDO::query() - it seems the query is running unbuffered (why else would the change in result set size 'fix' the issue?). Here is my code to reproduce the problem: ?php $Database = new PDO( 'mysql:host=localhost;port=3306;dbname=mydatabase', 'root', '', array( PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION, PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = true ) ); $rQuery = $Database-query('SELECT id FROM mytable'); // This is never reached because the result set is too large echo 'Made it through.'; foreach($rQuery as $aRow) { print_r($aRow); } ? If I limit the query with some reasonable number, it works fine: $rQuery = $Database-query('SELECT id FROM mytable LIMIT 10'); I have tried playing with PDO::MYSQL_ATTR_MAX_BUFFER_SIZE and using the PDO::prepare() and PDO::execute() as well (though there are no parameters in the above query), both to no avail. Any help would be appreciated, Stewart -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO buffered query problem
Stewart Duncan wrote: Hi there, I'm having some serious problems with the PHP Data Object functions. I'm trying to loop through a sizeable result set (~60k rows, ~1gig) using a buffered query to avoid fetching the whole set. No matter what I do, the script just hangs on the PDO::query() - it seems the query is running unbuffered (why else would the change in result set size 'fix' the issue?). Here is my code to reproduce the problem: ?php $Database = new PDO( 'mysql:host=localhost;port=3306;dbname=mydatabase', 'root', '', array( PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION, PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = true ) ); Don't you want it the other way around? You want it unbuffered so it doesn't get retrieved in mysql, send the whole result set to php then you can use it. You want to start using it immediately - so make it unbuffered. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] pdo and dabase schema
Alain Roger wrote: Hi, is there a way with PDO class to not have: - to execute a simple SET search_path TO myschema; can you alter the postgres users path? alter user username set search_path to new_schema, current_schemas(); or some variation on that. - and after to fletch another SQL request, like select to be sure that the SQL statement will be perform on this schema ? (basically i want to do it in 1 step) You can't. After you connect you have to change the schema. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO
Hi, i'm currently using PDO as it seems better than any other pg_connect and so on... however, i experience issue testing it. for example the following code returns me the correct records (count and records themselve) $sql =SELECT * FROM sewe.languages;; $result = DatabaseHandler::Prepare($sql); //$res=DatabaseHandler::Execute($result); $rec = DatabaseHandler::GetAll($result); echo Amount of records : .count($rec).br/; for ($i = 0; $i count($rec); $i++) { print Record ID : .$rec[$i]['id']. / Abbreviation : .$rec[$i]['abbreviation']. / Description :.$rec[$i]['description'].br/; } however if i replace this simple SQL request by my function./stored procedure like that : $sql = 'select * from get_languages_list(*);'; it does not work...in fact it returns me 0 as count of record, whereas under postgreSQL pgAdmin interface the same syntax of SQL request returns me the same result as the previous SQL selct * from... so where could be the issue when PDO uses stored procedures/functions ? thx. -- Alain Windows XP SP3 PostgreSQL 8.2.4 / MS SQL server 2005 Apache 2.2.4 PHP 5.2.4 C# 2005-2008
[PHP] pdo and dabase schema
Hi, is there a way with PDO class to not have: - to execute a simple SET search_path TO myschema; - and after to fletch another SQL request, like select to be sure that the SQL statement will be perform on this schema ? (basically i want to do it in 1 step) because i tried to specify the schema into my sql statement but in this case PDO returns me 0 record. thanks a lot, -- Alain Windows XP SP3 PostgreSQL 8.2.4 / MS SQL server 2005 Apache 2.2.4 PHP 5.2.4 C# 2005-2008
[PHP] PDO, sqlite write requests (INSERT) don't working
Hi, it's the first time I use sqlite in PHP script. All read requests work perfectly but I don't get on execute write requests. Example : ?php try { $dbh = new PDO(sqlite:../example1.sqlite, '', ''); } catch (PDOException $e) { echo Connection failed: . $e-getMessage(); } var_dump($dbh); $firstname = foobarbbar; $lastname = barbarbar; try { $sql = INSERT INTO contact (firstname, lastname) VALUES('.addslashes($firstname).', '.addslashes($lastname).'); $result = $dbh-exec($sql); var_dump($result); } catch(PDOExecption $e) { print Error!: . $e-getMessage() . /br; } ? $ ls ../ -lha ... -rw-rw-rw- 1 stephane stephane 237K 2008-08-19 21:09 example1.sqlite ... When I launch this script INSERT request don't work, nothing is inserted in contact table. var_dump($result) return : bool(false) Have you already see this issue ? What is my mistake ? Thanks for your help, Stephane -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO, sqlite write requests (INSERT) don't working
Hi KLEIN, I think the problem is where you are connecting to your database. I've not used SQL lite before, but the function spec says that you have too many arguments. It suggests connecting like this: if ($db = new SQLiteDatabase('filename')) Also, do you need to specify the sqlite: protocol before the path? Does the system even know what this path is? One further note; you are using a relative path, but is it relative to the right location? Does it have to be relative to the system runtime or the PHP file? Try an absolute path to see if that fixes it. Ash www.ashleysheridan.co.uk ---BeginMessage--- Hi, it's the first time I use sqlite in PHP script. All read requests work perfectly but I don't get on execute write requests. Example : ?php try { $dbh = new PDO(sqlite:../example1.sqlite, '', ''); } catch (PDOException $e) { echo Connection failed: . $e-getMessage(); } var_dump($dbh); $firstname = foobarbbar; $lastname = barbarbar; try { $sql = INSERT INTO contact (firstname, lastname) VALUES('.addslashes($firstname).', '.addslashes($lastname).'); $result = $dbh-exec($sql); var_dump($result); } catch(PDOExecption $e) { print Error!: . $e-getMessage() . /br; } ? $ ls ../ -lha ... -rw-rw-rw- 1 stephane stephane 237K 2008-08-19 21:09 example1.sqlite ... When I launch this script INSERT request don't work, nothing is inserted in contact table. var_dump($result) return : bool(false) Have you already see this issue ? What is my mistake ? Thanks for your help, Stephane -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php ---End Message--- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] pdo compilation question
Quoting Tim Rupp [EMAIL PROTECTED]: Hi list, I hope this is the right area to ask, I'm trying to compile PDO support in 5.2.6 and am following the instructions here http://us2.php.net/manual/en/pdo.installation.php My compile line is the following ./configure --enable-force-cgi-redirect \ --disable-rpath \ --with-bz2 \ --with-db4=/usr \ --with-curl \ --with-gd \ --enable-gd-native-ttf \ --without-gdbm \ --with-gettext \ --with-ncurses \ --with-gmp \ --with-iconv \ --with-openssl \ --with-regex=system \ --with-zlib \ --with-layout=GNU \ --enable-bcmath \ --enable-exif \ --enable-ftp \ --enable-magic-quotes \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-wddx \ --with-kerberos \ --with-ldap=shared \ --with-mysql=shared \ --enable-mbstring=all \ --with-apxs2=/usr/sbin/apxs \ --with-pgsql=shared \ --with-mysqli \ --with-freetype-dir=/usr/include/freetype2 \ --with-mcrypt \ --enable-soap \ --enable-pcntl \ --enable-pdo=shared \ --with-sqlite=shared \ --with-pdo-sqlite=shared \ --with-pdo-mysql=shared \ --with-pdo-pgsql=shared \ --with-pdo-oci=shared This config line I'm working with has been a growing one, so there may be some things here that may or may not be needed. Anyway, Upon compiling the above, I get the following error when I do a php -m Warning: PHP Startup: Invalid library (maybe not a PHP library) 'pdo.so' in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/pdo_mysql.so' - /usr/local/lib/php/20060613/pdo_mysql.so: undefined symbol: php_pdo_get_dbh_ce in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/pdo_pgsql.so' - /usr/local/lib/php/20060613/pdo_pgsql.so: undefined symbol: php_pdo_register_driver in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/pdo_sqlite.so' - /usr/local/lib/php/20060613/pdo_sqlite.so: undefined symbol: php_pdo_register_driver in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/sqlite.so' - /usr/local/lib/php/20060613/sqlite.so: undefined symbol: php_pdo_register_driver in Unknown on line 0 I've included the extensions in my php.ini file, but I'm completely lost on where to go from here because the error is less than helpful. The order that I've included them is extension=pdo.so extension=pdo_mysql.so extension=pdo_pgsql.so extension=pdo_sqlite.so extension=sqlite.so and they do exist, as shown here -rwxr-xr-x 1 root root 364012 May 14 2007 apc.so -rwxr-xr-x 1 root root 102531 Aug 18 14:25 ldap.so -rwxr-xr-x 1 root root 120644 Aug 18 14:25 mysql.so -rwxr-xr-x 1 root root 270860 Nov 13 2006 oci8.so -rwxr-xr-x 1 root root 125246 Aug 18 14:25 pdo_mysql.so -rwxr-xr-x 1 root root 100772 Aug 18 14:25 pdo_oci.so -rwxr-xr-x 1 root root 111246 Aug 18 14:25 pdo_pgsql.so -rwxr-xr-x 1 root root 270276 Aug 18 14:25 pdo.so -rwxr-xr-x 1 root root 1370516 Aug 18 14:25 pdo_sqlite.so -rwxr-xr-x 1 root root 235943 Aug 18 14:25 pgsql.so -rwxr-xr-x 1 root root 1010437 Aug 18 14:25 sqlite.so -rwxr-xr-x 1 root root 598407 Jan 29 2008 xdebug.so I'm using RHEL 4, and have installed the sqlite-devel, but I think php is choosing to use the sqlite that comes with it I'm hoping someone on the list can point me in the right direction. Thanks in advance, Tim you are loading extensions of an older PHP version. Do an ls -als on /usr/local/lib/php. you will find a directory with a higher date. That's your new extension path. Just change the location in the php.ini to reflect the new location. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] pdo compilation question
Thijs Lensselink schreef: Quoting Tim Rupp [EMAIL PROTECTED]: ... Thanks in advance, Tim you are loading extensions of an older PHP version. Do an ls -als on /usr/local/lib/php. you will find a directory with a higher date. That's your new extension path. Just change the location in the php.ini to reflect the new location. I'd second that, I'd also say that you might consider compiling the extensions in statically and save the hassle of having to load the .so files, if you still don't get anywhere. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] pdo compilation question
Hi list, I hope this is the right area to ask, I'm trying to compile PDO support in 5.2.6 and am following the instructions here http://us2.php.net/manual/en/pdo.installation.php My compile line is the following ./configure --enable-force-cgi-redirect \ --disable-rpath \ --with-bz2 \ --with-db4=/usr \ --with-curl \ --with-gd \ --enable-gd-native-ttf \ --without-gdbm \ --with-gettext \ --with-ncurses \ --with-gmp \ --with-iconv \ --with-openssl \ --with-regex=system \ --with-zlib \ --with-layout=GNU \ --enable-bcmath \ --enable-exif \ --enable-ftp \ --enable-magic-quotes \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-wddx \ --with-kerberos \ --with-ldap=shared \ --with-mysql=shared \ --enable-mbstring=all \ --with-apxs2=/usr/sbin/apxs \ --with-pgsql=shared \ --with-mysqli \ --with-freetype-dir=/usr/include/freetype2 \ --with-mcrypt \ --enable-soap \ --enable-pcntl \ --enable-pdo=shared \ --with-sqlite=shared \ --with-pdo-sqlite=shared \ --with-pdo-mysql=shared \ --with-pdo-pgsql=shared \ --with-pdo-oci=shared This config line I'm working with has been a growing one, so there may be some things here that may or may not be needed. Anyway, Upon compiling the above, I get the following error when I do a php -m Warning: PHP Startup: Invalid library (maybe not a PHP library) 'pdo.so' in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/pdo_mysql.so' - /usr/local/lib/php/20060613/pdo_mysql.so: undefined symbol: php_pdo_get_dbh_ce in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/pdo_pgsql.so' - /usr/local/lib/php/20060613/pdo_pgsql.so: undefined symbol: php_pdo_register_driver in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/pdo_sqlite.so' - /usr/local/lib/php/20060613/pdo_sqlite.so: undefined symbol: php_pdo_register_driver in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/sqlite.so' - /usr/local/lib/php/20060613/sqlite.so: undefined symbol: php_pdo_register_driver in Unknown on line 0 I've included the extensions in my php.ini file, but I'm completely lost on where to go from here because the error is less than helpful. The order that I've included them is extension=pdo.so extension=pdo_mysql.so extension=pdo_pgsql.so extension=pdo_sqlite.so extension=sqlite.so and they do exist, as shown here -rwxr-xr-x 1 root root 364012 May 14 2007 apc.so -rwxr-xr-x 1 root root 102531 Aug 18 14:25 ldap.so -rwxr-xr-x 1 root root 120644 Aug 18 14:25 mysql.so -rwxr-xr-x 1 root root 270860 Nov 13 2006 oci8.so -rwxr-xr-x 1 root root 125246 Aug 18 14:25 pdo_mysql.so -rwxr-xr-x 1 root root 100772 Aug 18 14:25 pdo_oci.so -rwxr-xr-x 1 root root 111246 Aug 18 14:25 pdo_pgsql.so -rwxr-xr-x 1 root root 270276 Aug 18 14:25 pdo.so -rwxr-xr-x 1 root root 1370516 Aug 18 14:25 pdo_sqlite.so -rwxr-xr-x 1 root root 235943 Aug 18 14:25 pgsql.so -rwxr-xr-x 1 root root 1010437 Aug 18 14:25 sqlite.so -rwxr-xr-x 1 root root 598407 Jan 29 2008 xdebug.so I'm using RHEL 4, and have installed the sqlite-devel, but I think php is choosing to use the sqlite that comes with it I'm hoping someone on the list can point me in the right direction. Thanks in advance, Tim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] [PHP-DEV] Re: [PHP] PDO prepared statements and LIKE escaping
Sorry - switched address to the wrong list :( *I* hate reply not going to the right place - but one of these days I switch to something that just ignores the on board miss direction ;) Larry Garfield wrote: I'm building a multi-database system, although my main targets are MySQL, Postgres, and SQLite. How would those handle something like a string that ends in 100%? Personally this is one of the reasons that PDO has never attracted me. Providing the tools to flatten some of the differences between *SQL* variations is just as important as flattening the name differences in functions. My own use of LIKE tends to process the string and then add the wrapping %% when passing it to the param array, but do all databases HANDLE 'escaped %' in the LIKE data? Firebird allows a escape character but you need to include it in the SQL LIKE '%100#%%' ESCAPE '#' But I think MySQL actually uses \% to achieve the same thing - and the ESCAPE '\' is then optional? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
On Mon, Aug 4, 2008 at 1:36 AM, Larry Garfield [EMAIL PROTECTED] wrote: Hi folks. I am trying to figure out the best way to handle an interesting issue in PDO prepared statements. Consider: $search = 'mystring'; $stmt = $dbh-prepare(SELECT * FROM mytable WHERE myfield LIKE :myfield); $stmt-execute(array(':myfield' = $search . '%')); The above will search for any record whose myfield entry begins with the value in $search. Great. And because it's a prepared statement, the database handles SQL injection protection for us. According to the manual, that is the correct way of handling LIKE statements: http://us3.php.net/manual/en/pdo.prepared-statements.php (See Example #6) But! Now consider this: $search = 100% pure PHP; When that is run, the % in the literal string will get interpreted by the SQL server as another wildcard character. That is not desired. IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not? We also cannot use $dbh-quote(), as that is intended for cases where you're building a query string directly rather than using a prepared statement. How do other folks handle this issue? -- Larry Garfield [EMAIL PROTECTED] I don't see any way around it, nor do I see it as defeating the purpose of prepared statements. I also don't see that this is any special limitation of PDO when compared to any other database library. How can any escaping mechanism know that in one case you are looking for a literal percent sign and in another you are using a wildcard? You have to provide it with hints, which is what the escape character does. Escaping a percent sign inside a string literal used as the pattern for a LIKE comparison is not the same thing as escaping single quotes within a string. Most of the time a percent sign in a pattern will be a wildcard; matching a literal percent sign is usually the exception. If you fail to escape a percent sign in your condition, the query will still execute successfully. You may get more (but not less) results than you desired or intended, but it will still work. However, if you fail to escape literal delimiters like single quotes, your query will not (usually) run at all. (And if it does run, it will likely produce undesired results or side effects, which is the definition of SQL injection.) As I see it, this is one of the purposes of prepared statements. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not? Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is generally why I can't be bothered with prepared statements in php. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen [EMAIL PROTECTED] wrote: Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not?=20 Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is= generally why I can't be bothered with prepared statements in php.=20 Actually in most cases in PHP you don't get much performance. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
Larry Garfield wrote: Actually in most cases in PHP you don't get much performance. Exactly. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. I don't really buy that - the string escaping is just a call to a mysql API, surely that's perfectly reliable. How do you see prepared statements being cleaner and more reliable? /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen [EMAIL PROTECTED] wrote: Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not?=20 Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is= generally why I can't be bothered with prepared statements in php.=20 Actually in most cases in PHP you don't get much performance. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. --Larry Garfield True. I wish PDO would add an option of creating a parameterized query WITHOUT preparing it, at least for SQL Server. Why? There is overhead to creating the statement that way. I prefer using the prepared statement method as it decreases the exposure and risk to SQL injection. I'd like to see an option like the Microsoft ADO library so that I can prepare the statement if I will be running it several times with different parameter values each time, or choose not to incur the overhead if I'm only going to run a statement once. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
On Mon, 4 Aug 2008 11:48:39 -0400, Andrew Ballard [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen [EMAIL PROTECTED] wrote: Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not?=20 Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is= generally why I can't be bothered with prepared statements in php.=20 Actually in most cases in PHP you don't get much performance. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. --Larry Garfield True. I wish PDO would add an option of creating a parameterized query WITHOUT preparing it, at least for SQL Server. Why? There is overhead to creating the statement that way. I prefer using the prepared statement method as it decreases the exposure and risk to SQL injection. I'd like to see an option like the Microsoft ADO library so that I can prepare the statement if I will be running it several times with different parameter values each time, or choose not to incur the overhead if I'm only going to run a statement once. I've solved that at least for the given page request with a caching layer on top of PDO. It caches and reuses the statement objects. The problem is the issue with LIKE as described above, which I still haven't figured out yet. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PDO prepared statements and LIKE escaping
-Original Message- From: Andrew Ballard [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 10:49 AM To: PHP General list Subject: Re: [PHP] PDO prepared statements and LIKE escaping On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen [EMAIL PROTECTED] wrote: Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not?=20 Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is= generally why I can't be bothered with prepared statements in php.=20 Actually in most cases in PHP you don't get much performance. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. --Larry Garfield True. I wish PDO would add an option of creating a parameterized query WITHOUT preparing it, at least for SQL Server. Why? There is overhead to creating the statement that way. I prefer using the prepared statement method as it decreases the exposure and risk to SQL injection. I'd like to see an option like the Microsoft ADO library so that I can prepare the statement if I will be running it several times with different parameter values each time, or choose not to incur the overhead if I'm only going to run a statement once. I believe that (and don't quote me on this) newer versions of SQL Server are setup to where EVERYTHING is compiled, even ordinary statements. A lot of the reading I have done about execution paths of SQL Server queries lead me to believe that they're all handled in a generic manner by default. 'Course... I could be wrong, or perhaps I was reading about special case scenarios. Todd Boyd Web Programmer
Re: [PHP] PDO prepared statements and LIKE escaping
Larry, I agree that having to escape values in a stored procedure does run counter to expectations. It's likely other developers have the potential for short-circuiting their LIKE conditions without realizing it. I've dealt with this issue, too, and haven't been especially pleased with any of the solutions I've undertaken. Recently, I've been avoiding LIKE conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the potential for unescaped wildcards. Adam On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield [EMAIL PROTECTED]wrote: On Mon, 4 Aug 2008 11:48:39 -0400, Andrew Ballard [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen [EMAIL PROTECTED] wrote: Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not?=20 Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is= generally why I can't be bothered with prepared statements in php.=20 Actually in most cases in PHP you don't get much performance. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. --Larry Garfield True. I wish PDO would add an option of creating a parameterized query WITHOUT preparing it, at least for SQL Server. Why? There is overhead to creating the statement that way. I prefer using the prepared statement method as it decreases the exposure and risk to SQL injection. I'd like to see an option like the Microsoft ADO library so that I can prepare the statement if I will be running it several times with different parameter values each time, or choose not to incur the overhead if I'm only going to run a statement once. I've solved that at least for the given page request with a caching layer on top of PDO. It caches and reuses the statement objects. The problem is the issue with LIKE as described above, which I still haven't figured out yet. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
Hm. So your solution is don't use LIKE? I can't say I'm wild about that. :-/ --Larry Garfield On Mon, 4 Aug 2008 15:49:52 -0400, Adam Richardson [EMAIL PROTECTED] wrote: Larry, I agree that having to escape values in a stored procedure does run counter to expectations. It's likely other developers have the potential for short-circuiting their LIKE conditions without realizing it. I've dealt with this issue, too, and haven't been especially pleased with any of the solutions I've undertaken. Recently, I've been avoiding LIKE conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the potential for unescaped wildcards. Adam On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield [EMAIL PROTECTED]wrote: On Mon, 4 Aug 2008 11:48:39 -0400, Andrew Ballard [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen [EMAIL PROTECTED] wrote: Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not?=20 Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is= generally why I can't be bothered with prepared statements in php.=20 Actually in most cases in PHP you don't get much performance. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
Like I said, I'm not 'especially pleased' with any idea up until now. I'm certainly open to any other ideas. Adam On Mon, Aug 4, 2008 at 6:57 PM, Larry Garfield [EMAIL PROTECTED]wrote: Hm. So your solution is don't use LIKE? I can't say I'm wild about that. :-/ --Larry Garfield On Mon, 4 Aug 2008 15:49:52 -0400, Adam Richardson [EMAIL PROTECTED] wrote: Larry, I agree that having to escape values in a stored procedure does run counter to expectations. It's likely other developers have the potential for short-circuiting their LIKE conditions without realizing it. I've dealt with this issue, too, and haven't been especially pleased with any of the solutions I've undertaken. Recently, I've been avoiding LIKE conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the potential for unescaped wildcards. Adam On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield [EMAIL PROTECTED]wrote: On Mon, 4 Aug 2008 11:48:39 -0400, Andrew Ballard [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen [EMAIL PROTECTED] wrote: Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not?=20 Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is= generally why I can't be bothered with prepared statements in php.=20 Actually in most cases in PHP you don't get much performance. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
Depending on what database you're using you might be able to use LIKE while maintaining security. For instance PostgreSQL has the functions quote_ident(), and quote_literal() which would allow you to use LIKE since these functions would automatically make the string suitable for comparison. So for instance in a stored procedure in PostgreSQL you could do: SELECT * FROM sometable WHERE quote_ident(column) LIKE quote_ident($1); Note that in the above line $1 would be the first parameter of the stored procedure. -Asher Adam Richardson wrote: Like I said, I'm not 'especially pleased' with any idea up until now. I'm certainly open to any other ideas. Adam On Mon, Aug 4, 2008 at 6:57 PM, Larry Garfield [EMAIL PROTECTED]wrote: Hm. So your solution is don't use LIKE? I can't say I'm wild about that. :-/ --Larry Garfield On Mon, 4 Aug 2008 15:49:52 -0400, Adam Richardson [EMAIL PROTECTED] wrote: Larry, I agree that having to escape values in a stored procedure does run counter to expectations. It's likely other developers have the potential for short-circuiting their LIKE conditions without realizing it. I've dealt with this issue, too, and haven't been especially pleased with any of the solutions I've undertaken. Recently, I've been avoiding LIKE conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the potential for unescaped wildcards. Adam On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield [EMAIL PROTECTED]wrote: On Mon, 4 Aug 2008 11:48:39 -0400, Andrew Ballard [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen [EMAIL PROTECTED] wrote: Larry Garfield wrote: IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not?=20 Depends on what you perceive the purpose of the prepared statement to be :-) In this context, I tend to think of performance only. Which is= generally why I can't be bothered with prepared statements in php.=20 Actually in most cases in PHP you don't get much performance. What you do get is added security, because prepared statements are cleaner than cleaner and more reliable than string escaping. Of course, then we run into the % problem above. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO prepared statements and LIKE escaping
I'm building a multi-database system, although my main targets are MySQL, Postgres, and SQLite. How would those handle something like a string that ends in 100%? On Monday 04 August 2008 6:18:24 pm Asher Snyder wrote: Depending on what database you're using you might be able to use LIKE while maintaining security. For instance PostgreSQL has the functions quote_ident(), and quote_literal() which would allow you to use LIKE since these functions would automatically make the string suitable for comparison. So for instance in a stored procedure in PostgreSQL you could do: SELECT * FROM sometable WHERE quote_ident(column) LIKE quote_ident($1); Note that in the above line $1 would be the first parameter of the stored procedure. -Asher Adam Richardson wrote: Like I said, I'm not 'especially pleased' with any idea up until now. I'm certainly open to any other ideas. Adam On Mon, Aug 4, 2008 at 6:57 PM, Larry Garfield [EMAIL PROTECTED]wrote: Hm. So your solution is don't use LIKE? I can't say I'm wild about that. :-/ --Larry Garfield -- Larry Garfield [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO prepared statements and LIKE escaping
Hi folks. I am trying to figure out the best way to handle an interesting issue in PDO prepared statements. Consider: $search = 'mystring'; $stmt = $dbh-prepare(SELECT * FROM mytable WHERE myfield LIKE :myfield); $stmt-execute(array(':myfield' = $search . '%')); The above will search for any record whose myfield entry begins with the value in $search. Great. And because it's a prepared statement, the database handles SQL injection protection for us. According to the manual, that is the correct way of handling LIKE statements: http://us3.php.net/manual/en/pdo.prepared-statements.php (See Example #6) But! Now consider this: $search = 100% pure PHP; When that is run, the % in the literal string will get interpreted by the SQL server as another wildcard character. That is not desired. IIRC, the way in SQL to circumvent that is to convert 100% into 100%%. However, that does rather defeat the purpose of a prepared statement if I have to do my own escaping anyway, does it not? We also cannot use $dbh-quote(), as that is intended for cases where you're building a query string directly rather than using a prepared statement. How do other folks handle this issue? -- Larry Garfield [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Question. Number of rows returned
Kevin Waterson wrote: I am switching to PDO and can't find an equivalent to mysql_num_rows. Am I missing something silly? Or is there a change of thinking needed for PDO? How should I determine how many rows a query returned? PDO returns an array, sizeof/count will get you home I would like to know how many rows I am working with before starting to fetch. Also fetchall, does not seem to have a style that returns each column value just once. I see this ugly thing in the manual: Fetch all of the remaining rows in the result set: Array ( [0] = Array ( [NAME] = pear [0] = pear [COLOUR] = green [1] = green ) [1] = Array ( [NAME] = watermelon [0] = watermelon [COLOUR] = pink [1] = pink ) ) If I could get the column offsets only, without the column names I would be very happy. Stephen -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Question. Number of rows returned
On Sun, Jul 13, 2008 at 10:30 AM, Stephen [EMAIL PROTECTED] wrote: Kevin Waterson wrote: I am switching to PDO and can't find an equivalent to mysql_num_rows. Am I missing something silly? Or is there a change of thinking needed for PDO? How should I determine how many rows a query returned? PDO returns an array, sizeof/count will get you home I would like to know how many rows I am working with before starting to fetch. Also fetchall, does not seem to have a style that returns each column value just once. I see this ugly thing in the manual: Fetch all of the remaining rows in the result set: Array ( [0] = Array ( [NAME] = pear [0] = pear [COLOUR] = green [1] = green ) [1] = Array ( [NAME] = watermelon [0] = watermelon [COLOUR] = pink [1] = pink ) ) If I could get the column offsets only, without the column names I would be very happy. Stephen -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php http://ca3.php.net/manual/en/pdostatement.rowcount.php -- Bastien Cat, the other other white meat
Re: [PHP] PDO Question. Number of rows returned
Bastien Koert wrote: On Sun, Jul 13, 2008 at 10:30 AM, Stephen [EMAIL PROTECTED] wrote: Kevin Waterson wrote: I am switching to PDO and can't find an equivalent to mysql_num_rows. Am I missing something silly? Or is there a change of thinking needed for PDO? How should I determine how many rows a query returned? PDO returns an array, sizeof/count will get you home I would like to know how many rows I am working with before starting to fetch. Also fetchall, does not seem to have a style that returns each column value just once. I see this ugly thing in the manual: Fetch all of the remaining rows in the result set: Array ( [0] = Array ( [NAME] = pear [0] = pear [COLOUR] = green [1] = green ) [1] = Array ( [NAME] = watermelon [0] = watermelon [COLOUR] = pink [1] = pink ) ) If I could get the column offsets only, without the column names I would be very happy. http://ca3.php.net/manual/en/pdostatement.rowcount.php This is only good for updates, inserts and deletes.br I am just doing a select. Stephenbr -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Question. Number of rows returned
On Sun, Jul 13, 2008 at 11:12 AM, Stephen [EMAIL PROTECTED] wrote: Bastien Koert wrote: On Sun, Jul 13, 2008 at 10:30 AM, Stephen [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Kevin Waterson wrote: I am switching to PDO and can't find an equivalent to mysql_num_rows. Am I missing something silly? Or is there a change of thinking needed for PDO? How should I determine how many rows a query returned? PDO returns an array, sizeof/count will get you home I would like to know how many rows I am working with before starting to fetch. Also fetchall, does not seem to have a style that returns each column value just once. I see this ugly thing in the manual: Fetch all of the remaining rows in the result set: Array ( [0] = Array ( [NAME] = pear [0] = pear [COLOUR] = green [1] = green ) [1] = Array ( [NAME] = watermelon [0] = watermelon [COLOUR] = pink [1] = pink ) ) If I could get the column offsets only, without the column names I would be very happy. Stephen http://ca3.php.net/manual/en/pdostatement.rowcount.php This is only good for updates, inserts and deletes. I am just doing a select. Stephen my bad. Note you can change the default return array behaviour by change the FETCH_STYLE, default is both ordinal and col name -- Bastien Cat, the other other white meat
[PHP] PDO Question. Number of rows returned
I am switching to PDO and can't find an equivalent to mysql_num_rows. Am I missing something silly? Or is there a change of thinking needed for PDO? How should I determine how many rows a query returned? Thanks Stephen -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO Question. Number of rows returned
This one time, at band camp, Stephen [EMAIL PROTECTED] wrote: I am switching to PDO and can't find an equivalent to mysql_num_rows. Am I missing something silly? Or is there a change of thinking needed for PDO? How should I determine how many rows a query returned? PDO returns an array, sizeof/count will get you home Kevin http://phpro.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP + PDO + MySQL + Stored Procedure + PREPARE = Problem
Hi all, I've found a bug when working on a PHP script using a PDO connector. When I made a Store Procedure using the PREPARE statement something messed up the result im my PHP script. Please go to my blog http://huzed.com/zed/?p=21 and see code. Tanks for help. ZED -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO::ATTR_TIMEOUT script specific?
On Thu, August 2, 2007 1:49 pm, Ken Tozier wrote: I have a script that needs to get ad information from two different sources, a primary and fallback. The primary source is a high traffic (and poorly designed/unpartitioned MSSQL database) with millions of records that gets locked up when 'certain folks' (ie executives) perform large queries. What I'd like to be able to do is set a timeout for a query to this database of 5 to 10 seconds and branch to the fallback database if the timeout expires. I can't just use the fallback as my primary as it doesn't always have the most up to date info. It's really only for placeholder queries until the primary frees up. So the question is, does setting PDO::ATTR_TIMEOUT affect all scripts or just the one that set the variable? Two off-the-wall suggestions: #1. Get the executives to use a super-special reports replicated copy of the database so that they don't take down your entire website every time they write some stupid ad hoc query. This is kind of crucial regardless of how you solve the problem you are having today. #2. If PDO does NOT do what you need, maybe switch to mssql or sybase extension driver and use an asynchronous query that you can poll to see if it has finished or not. I'm pretty sure these are available in MSSQL with those drivers, though not 100% sure. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PDO lastInsertID always returns zero for MySQL tables
Hi In the past, I always used mysql_insert_id() and never had a problem, but now that I'm using PDO, I'm finding that it always returns zero. The tables are identical between the two methods but where mysql_insert_id works $pdo_connection-lastInsertID() doesn't. The PDO documentation states that you need to feed lastInsertID something called a sequence object. I'd never heard of those before so after some reading here http://www.mckoi.com/database/ SQLSyntax.html#7 it looks like you have to create these yourself . But MySQL tables already seem to have a built-in sequence (as evidenced by the auto_increment flag when creating tables) and creating another one for a given table could lead to id collisions. So basically, the question is: Is it possible to get valid lastInsertIds: using PDO with a MySQL database that mirrors the behavior of mysql_insert_id? Thanks for any help Ken Here' the function. The lastInsertID call comes in the 'else' branch of the if (strpos ($query, 'insert') === false) test function query_database($inQuery) { $query = $inQuery; $coersions = null; $object_key = null; $group_by_key = null; if (is_array($inQuery)) { $query = $inQuery['query']; $coersions = $inQuery['coersions']; $object_key = $inQuery['object_key']; $group_by_key = $inQuery['group_by_key']; } try { // determine query type if (strpos($query, 'insert') === false) { $rows = array(); $rowCounter = 0; foreach ($this-db-query($query, PDO::FETCH_NAMED) as $row) { $rowFields = array(); $recordKey = $rowCounter; foreach ($row as $key = $value) { // remember this key if it matches the user specified object key if (($object_key != null) ($key == $object_key)) $recordKey = $value; // perform user specified coersions if ($coersions != null) $value = $this-coerce_value($value, $coersions[$key]); $rowFields[$key] = $value; } // perform grouping if requested if ($group_by_key == null) $rows[$recordKey] = $rowFields; else { $groupKey = $rowFields[$group_by_key]; if ($rows[$groupKey] == null) $rows[$groupKey]= array(); $rows[$groupKey][] = $rowFields; } $rowCounter++; } return $rows; } else { // next line prints OK on inserts echo 'query type was: insertbr'; // but this always returns zero return ($this-db-lastInsertId()); } } catch (PDOException $error) { print Error!: . $error-getMessage() . br/; die(); } } -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO lastInsertID always returns zero for MySQL tables [SOLVED]
Disregard. After more head scratching I found that I was branching to the 'insert' handler without calling this-db-query($query). On Aug 5, 2007, at 9:18 PM, Ken Tozier wrote: Hi In the past, I always used mysql_insert_id() and never had a problem, but now that I'm using PDO, I'm finding that it always returns zero. The tables are identical between the two methods but where mysql_insert_id works $pdo_connection-lastInsertID() doesn't. The PDO documentation states that you need to feed lastInsertID something called a sequence object. I'd never heard of those before so after some reading here http://www.mckoi.com/database/ SQLSyntax.html#7 it looks like you have to create these yourself . But MySQL tables already seem to have a built-in sequence (as evidenced by the auto_increment flag when creating tables) and creating another one for a given table could lead to id collisions. So basically, the question is: Is it possible to get valid lastInsertIds: using PDO with a MySQL database that mirrors the behavior of mysql_insert_id? Thanks for any help Ken Here' the function. The lastInsertID call comes in the 'else' branch of the if (strpos ($query, 'insert') === false) test function query_database($inQuery) { $query = $inQuery; $coersions = null; $object_key = null; $group_by_key = null; if (is_array($inQuery)) { $query = $inQuery['query']; $coersions = $inQuery['coersions']; $object_key = $inQuery['object_key']; $group_by_key = $inQuery['group_by_key']; } try { // determine query type if (strpos($query, 'insert') === false) { $rows = array(); $rowCounter = 0; foreach ($this-db-query($query, PDO::FETCH_NAMED) as $row) { $rowFields = array(); $recordKey = $rowCounter; foreach ($row as $key = $value) { // remember this key if it matches the user specified object key if (($object_key != null) ($key == $object_key)) $recordKey = $value; // perform user specified coersions if ($coersions != null) $value = $this-coerce_value($value, $coersions[$key]); $rowFields[$key] = $value; } // perform grouping if requested if ($group_by_key == null) $rows[$recordKey] = $rowFields; else { $groupKey = $rowFields[$group_by_key]; if ($rows[$groupKey] == null) $rows[$groupKey]= array(); $rows[$groupKey][] = $rowFields; } $rowCounter++; } return $rows; } else { // next line prints OK on inserts echo 'query type was: insertbr'; // but this always returns zero return ($this-db-lastInsertId()); } } catch (PDOException $error) { print Error!: . $error-getMessage() . br/; die(); } } -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php