Re: [PHP] PDO Transaction

2013-03-16 Thread Simon Dániel
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

2013-03-16 Thread Lester Caine

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

2013-03-15 Thread Simon Dániel
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

2013-03-15 Thread Lester Caine

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

2012-11-29 Thread admin
 -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

2012-11-28 Thread ad...@buskirkgraphics.com

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

2012-11-28 Thread ad...@buskirkgraphics.com
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

2012-11-28 Thread Mike Mackintosh
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

2012-11-28 Thread Admin

 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

2012-11-28 Thread Jim Lucas

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

2012-11-28 Thread Fatih P.
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

2012-10-22 Thread Silvio Siefke
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

2012-10-22 Thread Nathan Nobbe
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

2012-10-22 Thread Ashley Sheridan
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

2012-10-22 Thread Adam Richardson
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

2012-10-22 Thread Silvio Siefke
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

2012-10-22 Thread Lester Caine

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?

2012-07-15 Thread shiplu
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?

2012-07-15 Thread tamouse mailing lists
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?

2012-07-14 Thread tamouse mailing lists
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?

2012-07-14 Thread 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!


--
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?

2012-07-14 Thread Lester Caine

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?

2012-07-14 Thread Marco Behnke
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?

2012-07-13 Thread ma...@behnke.biz



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?

2012-07-13 Thread Paul M Foster
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?

2012-07-12 Thread tamouse mailing lists
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?

2012-07-03 Thread tamouse mailing lists
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?

2012-07-02 Thread Scott Baker
$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?

2012-07-02 Thread Matijn Woudt
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?

2012-07-02 Thread Scott Baker
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?

2012-07-02 Thread Matijn Woudt
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?

2012-07-02 Thread Jim Lucas

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 ?

2011-12-09 Thread Andreas

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

2010-12-21 Thread Adam Richardson
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

2010-12-21 Thread Rico Secada
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

2010-12-20 Thread Rico Secada
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

2010-12-20 Thread Paul M Foster
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

2010-12-20 Thread Rico Secada
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

2010-12-20 Thread Ravi Gehlot
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?

2010-12-15 Thread Nicholas Kell

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?

2010-12-14 Thread Sam Smith
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?

2010-12-14 Thread David Hutto
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?

2010-12-14 Thread Richard Quadling
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?

2010-12-14 Thread David Hutto
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?

2010-12-14 Thread Richard Quadling
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?

2010-12-14 Thread la...@garfieldtech.com
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?

2010-12-14 Thread Adam Richardson
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?

2010-12-14 Thread Lester Caine

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?

2010-12-14 Thread Govinda

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?

2010-12-14 Thread Paul M Foster
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?

2010-12-14 Thread Larry Garfield
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?

2010-10-18 Thread a...@ashleysheridan.co.uk
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?

2010-10-18 Thread Scott Baker

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?

2010-10-18 Thread Wez Furlong

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?

2010-10-18 Thread Scott Baker
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?

2010-10-18 Thread Stanley Sufficool
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

2010-07-21 Thread Sky Gunning
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

2010-07-21 Thread Peter Lind
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

2009-09-13 Thread Lester Caine
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?

2009-05-27 Thread Stephen
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

2009-04-16 Thread MEM
 
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
 
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

2009-04-15 Thread Thodoris


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

2009-04-15 Thread talofo talofo
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

2009-04-14 Thread MEM
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


Re: [PHP] PDO buffered query problem

2009-02-24 Thread Thodoris



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

2009-02-24 Thread Chris

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

2009-02-23 Thread Stewart Duncan

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

2009-02-23 Thread Chris

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

2008-10-15 Thread Chris

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

2008-10-14 Thread Alain Roger
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

2008-10-14 Thread Alain Roger
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

2008-08-20 Thread KLEIN Stéphane
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

2008-08-20 Thread Ashley Sheridan
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

2008-08-19 Thread Thijs Lensselink

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

2008-08-19 Thread Jochem Maas

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

2008-08-18 Thread Tim Rupp
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

2008-08-05 Thread Lester Caine

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

2008-08-05 Thread Andrew Ballard
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

2008-08-04 Thread Per Jessen
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

2008-08-04 Thread Larry Garfield

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

2008-08-04 Thread Per Jessen
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

2008-08-04 Thread Andrew Ballard
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

2008-08-04 Thread Larry Garfield

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

2008-08-04 Thread Boyd, Todd M.
 -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

2008-08-04 Thread Adam Richardson
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

2008-08-04 Thread Larry Garfield

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

2008-08-04 Thread Adam Richardson
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

2008-08-04 Thread Asher Snyder
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

2008-08-04 Thread Larry Garfield
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

2008-08-03 Thread Larry Garfield
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

2008-07-13 Thread Stephen

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

2008-07-13 Thread Bastien Koert
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

2008-07-13 Thread Stephen

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

2008-07-13 Thread Bastien Koert
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

2008-07-12 Thread Stephen

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

2008-07-12 Thread Kevin Waterson
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

2007-08-31 Thread Uzed

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?

2007-08-07 Thread Richard Lynch
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

2007-08-05 Thread Ken Tozier

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]

2007-08-05 Thread Ken Tozier

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



  1   2   >