[PHP] PDO: How to fetch TIMESTAMP values?

2006-01-24 Thread Michael Phillipson
I recently began evaluating the feasibility of reworking our current 
database access framework, which utilizes the PHP-native drivers for our 
database (Interbase), to one which makes use of the PDO extension. 
Unfortunately, I quickly hit a roadblock.

I have tried every permutation available in the PDO documentation, as far as 
I can see, in order to retrieve the value of a TIMESTAMP-type field from a 
given table, but so far I have been unsuccessful.

Using the PHP-native functions for Interbase, I used to be able to 
accomplish this with the following code:

?php
  $sql = SELECT TIMESTAMP_FIELD FROM MY_TABLE;
  $result = ibase_query($dbh, $sql);

  $row = ibase_fetch_row($result, IBASE_UNIXTIME);
  $field = $row[0];

  echo $field;
?

Here is one of the many [failed] methods I have attempted using a PDO:

?php
  $sql = SELECT TIMESTAMP_FIELD FROM MY_TABLE;
  $row = $dbh-query($sql);

  $field = $row['TIMESTAMP_FIELD'];

  echo $field;
?

In the first instance, a numeric (integer) value would be displayed on the 
screen.  In the PDO example, nothing is displayed.

I have also tried rewriting the PDO code above as a prepared statement, but 
i get the same result.

Has anyone else bumped up against problems with TIMESTAMP fields when using 
the Interbase PDO driver or some other?  Any suggestions would be 
appreciated.  Thanks! 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Persistent Database Connections

2005-04-26 Thread Michael Phillipson
Thanks, Philip (and Richard also), for offering your impressions.

Per Philip's suggestion, I ran ab (Apache Benchmark) to stress test the 
page that loads my persistent connection.  Depending on the parameters I set 
for ab, I was able to increase the number of connections from my initial 9 
to anywhere between 15 and 25.  This number varied from one test to 
another - even if I left the ab parameters the same.  I probably could have 
boosted the total connections even further by raising the number of 
connections/requests initiated by ab.

So, while I still don't have a rock-solid way to predict just how many 
connections will be opened for a given number of users, at least I'm not 
stuck at 9 :-)  I guess it took using an automated approach to simulating 
server load (e.g., ab) to force Apache to open additional connections to 
the database.

Interestingly, I also observed during my testing that some connections 
opened by Apache were subsequently closed.  So, this seems to answer my 
other question re. whether persistent connections stay open forever.  I 
guess they don't.  What seems clear is that Apache decides when to terminate 
active connections, not the database.

Thanks again.

Mike

Philip Hallstrom [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 What I am baffled by is the fact that the total nunber of connections
 between the web server and my database seems to max out at 9.  Why 9? 
 Not
 that I have a problem with this number.  I just want to understand how 
 this
 limit was reached so that I might predict how the application will 
 perform
 in a production capacity.

 I can't think of a reason it would max out at 9 other than perhaps you 
 really don't have more than 9 connections open.  My understanding is that 
 Apache will open a connection per child, per database connection where a 
 connection is made up of the host, user, and database.

 How many apache processes are running when you take this measurement? 
 There's no gaurantee that each of them will have hit your web app and 
 start up there own connection.

 You might use something like ab (apache benchmark) to hit a page that 
 initiates a persistent connection to see what happens as the number of 
 apache processes grows. 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] Persistent Database Connections

2005-04-25 Thread Michael Phillipson
[Please note that even though I cite Interbase in my example, I believe my 
question can be generalized to all databases that allow persistent 
connections]

I recently installed a trial version of Interbase on a development server 
that includes a nifty tool that allows me to monitor, among other things, 
the number of active connections to my server.  After playing with this 
feature briefly, I noticed that SEVERAL connections are opened between my 
web server and the database.  At first, I thought this was a little weird 
because I use the ibase_pconnect() function to establish communication with 
my database, and I expected to see only 1 connection.  However, after doing 
some reading, I discovered that this behavior is probably by design - the 
result of Apache spawning several child processes, each one establishing its 
own persistent connection(s) to the database.

What I am baffled by is the fact that the total nunber of connections 
between the web server and my database seems to max out at 9.  Why 9?  Not 
that I have a problem with this number.  I just want to understand how this 
limit was reached so that I might predict how the application will perform 
in a production capacity.

I have checked my Apache config (httpd.conf) file, and as far as I can tell, 
the maximum number of child processes is set to 20.  So again I ask: why 
does the number of connections max out at 9?  Shouldn't they max out at 20 
or 21 (1 parent + 20 children)?

And finally, I have noticed that the connections, once established, NEVER 
expire.  I realize that this is sort of the point with persistent 
connections, but I was curious whether persistent connections are ever 
terminated or recycled.

Any explanations/impressions would be appreciated.

Mike

FYI... My php.ini file is set to allow unlimited connections/unlimited 
persistent connections.  Also, the trial license of the database I am 
testing claims to be limited to 1 client, and the only client accessing the 
database is my web app.  Just thought I'd mention that as I don't think the 
number of connections has any direct correlation to the client license. 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php