#43887 [Com]: mssql2005 PROCEDURE PDO::PARAM_INPUT_OUTPUT
ID: 43887
Comment by: david dot wright at opticsplanet dot com
Reported By: coldgrass at gmail dot com
Status: No Feedback
Bug Type: PDO related
Operating System: *
PHP Version: 5.2.6
New Comment:
This is happening for me in 5.3.1., using Pdo_Dblib. Trying to call a
stored procedure on SQL Server 2005 server. Cannot retrieve a value.
PHP version 5.3.1
Using Pdo_Dblib
Linux: 2.6.24-24-server SMP x86_64 GNU/Linux
PHP Code:
/** SNIP. Set up a valid $db here! **/
$return_value = 999;
$sth = $db->prepare("EXEC dbo.opsp_Test ?");
$sth->bindParam(1, $return_value, PDO::PARAM_STR |
PDO::PARAM_INPUT_OUTPUT, 4);
$sth->execute();
echo "$return_value\n";
Return value ALWAYS comes back as 999, no matter what variations I try
in bindParam call.
Here's my Stored Procedure:
---
CREATE PROCEDURE opsp_Test
@TheOutputValue int OUTPUT
AS
BEGIN
SET @TheOutputValue = 11
END
Previous Comments:
[2009-05-03 01:00:06] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-04-25 14:54:04] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-11-26 22:39:06] aventurella at gmail dot com
forgot my php/OS version: 5.2.6 on OS X 10.5.5
[2008-11-26 22:37:50] aventurella at gmail dot com
I can confrim this on MySQL and PostgreSQL as well. No
PARAM_INPUT_OUTPUT values get bound through PDO when running a stored
procedure.
http://bugs.php.net/bug.php?id=46657
[2008-10-30 08:56:25] miha dot vrhovnik at domenca dot si
Can confirm this on Linux.
PHP 5.2.6, connecting to MSSQL 2000 via freetds 0.82RC4
Guys please fix that I had to revert back to mssql_* functions for
calling stored procedures. So Now half of project uses PDO the other
half the old functional style...
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43887
--
Edit this bug report at http://bugs.php.net/?id=43887&edit=1
#50555 [NEW]: Cannot retrieve output paramter from stored procedure
From: david dot wright at opticsplanet dot com
Operating system: 2.6.24-24-server
PHP version: 5.3.1
PHP Bug Type: PDO related
Bug description: Cannot retrieve output paramter from stored procedure
Description:
I cannot retrieve an output parameter from a stored procedure (in my case
on SQL Server 2005--am using PDO_DBLIB.
Reproduce code:
---
PHP Code:
---
/** SNIP. Set up a valid $db here! **/
$return_value = 999;
$sth = $db->prepare("EXEC dbo.opsp_Test ?");
$sth->bindParam(1, $return_value, PDO::PARAM_STR |
PDO::PARAM_INPUT_OUTPUT, 4);
$sth->execute();
echo "$return_value\n";
Stored Procedure
--
CREATE PROCEDURE opsp_Test
@TheOutputValue int OUTPUT
AS
BEGIN
SET @TheOutputValue = 11
END
Expected result:
output should be: 11
Actual result:
--
Output is 999 ($return_value unchanged)
--
Edit bug report at http://bugs.php.net/?id=50555&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50555&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50555&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50555&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50555&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50555&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50555&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50555&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50555&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50555&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50555&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50555&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50555&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50555&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50555&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50555&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50555&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50555&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50555&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50555&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50555&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50555&r=mysqlcfg
Bug #50916 [Com]: DateTime::sub repeats each time getTimestamp is called
Edit report at http://bugs.php.net/bug.php?id=50916&edit=1
ID: 50916
Comment by: david dot wright at opticsplanet dot com
Reported by:charlesb at itsmystuff dot com
Summary:DateTime::sub repeats each time getTimestamp is
called
Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Windows Server 2003 SP2
PHP Version:5.3.1
Block user comment: N
New Comment:
Problem is still alive and kicking under 5.3.2.
I had it happen repetition of prior sub() right after a call to
getTimeStamp().
Easily the most aggravating "not-my-bug-but-the-language-itself" I've
ever
encountered.
Previous Comments:
[2010-03-10 09:00:03] yoarvi at gmail dot com
The fix for http://bugs.php.net/bug.php?id=49059 fixes this problem as
well. I think this bug can be closed as a duplicate of 49059.
[2010-03-02 23:00:01] v-ryanbi at microsoft dot com
I've attached a patch that is tested on Windows, although the code that
needs to be changed appears to be universal. The patch also includes a
.phpt that compares the resulting timestamps.
The fix for this is a bit disconcerting for me, but as I'm not entirely
familiar with the codebase, I didn't want to muck things up too much.
Shouldn't the c function do_adjust_relative() in tm2unixtime.c be the
one to clear the flags it uses after it applies changes? If we're
clearing the flags in the calling functions, we're bound to miss more
stuff like this one.
[2010-02-20 10:28:40] pontus dot alexander at gmail dot com
This bug is confirmed to still be alive in snapshot "5.3-201002200930"
compiled on Debian Linux.
Reproduction code:
$Time = new \DateTime('NOW');
$Month = new \DateInterval('P1Y');
var_dump($Time);
// Correctly subtracted
$Time->sub($Month);
var_dump($Time);
// Wrongly subtracted
$Time->getTimestamp();
var_dump($Time);
[2010-02-02 18:04:23] charlesb at itsmystuff dot com
Description:
Each time DateTime::getTimestamp is called, a previously called
DateTime::sub value is applied. This does not occur with DateTime::add.
Reproduce code:
---
$work_time = new DateTime("2010-01-30 12:00:00");
$work_time->sub(new DateInterval("P7D"));
$window_start = $work_time->getTimestamp();
echo date("Y-m-d H:i:s", $window_start) . "";
$window_start = $work_time->getTimestamp();
echo date("Y-m-d H:i:s", $window_start) . "";
Expected result:
2010-01-23 12:00:00
2010-01-23 12:00:00
Actual result:
--
2010-01-16 12:00:00
2010-01-09 12:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=50916&edit=1
