For fucks sake would anybody already fix this? It's not the only report about this issue in the tracker.

This requires that pdo_dblib pass params using the RPC mechanisms and also to implement it's own driver level binding instead of relying on the PDO param binding. This will require a rewrite of most of the statement object.

Rest assured, it is being worked on but may take some time.

This bug/problem whatever you want to call it is not limkted to DBlib - happening on ODBC and SqlServer... Is anyone looking into this??

Working with the latest PHP 5.6 and MySQL 5.6.22 and can confirm this is still a bug and affects the PDO library.

I am experiencing the same issue with PHP 7.0.3, pdo_dblib and MSSQL 2008. Unfortunately I am having to resort to pdo_dblib due to the removal of mssql* functions.

Here is my code:

$db = new PDO('dblib:host=myhost:1433;dbname=mydb', 'username', 'password');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sql = "EXEC Stock_Level @myId=:myId, @StockLevel=:StockLevel";
$stmt = $db->prepare($sql);
$var = '12345';
$var2 = null;
$stmt->bindParam(":myId", $var, PDO::PARAM_STR);
$stmt->bindParam(":StockLevel", $var2, PDO::PARAM_INT|PDO::PARAM_INPUT_OUTPUT);

if(!$stmt->execute()) {
    echo "\nPDO::errorCode(): ", $stmt->errorCode();
}

echo "var 2 = " . $var2 . PHP_EOL;

This is a big problem!

Alternate test case in #70274.

This bug still persists in PHP 7.1.9

And since PHP 7.x has dropped support for the old mssql extension, this is now a very important bug, since it means there is no way to connect a Linux/BSD server to a Microsoft SQL server and have full stored procedure functionality.

I have tried both PDO_ODBC and PDO_DBLIB, different versions of FreeTDS (both with iODBC and UnixODBC backends), and I've found nothing that works for stored procedures with OUTPUT parameters.

You should be able to write a query where you:
 - DECLARE a var
 - run the sproc, using the var as the output parameter
 - SELECT the var

Not as elegant as being able to use bindParam, but it's a workaround.

That might work, but only if you're willing to rewrite an entire application with an ugly hack in order to upgrade to PHP 7.x

I really hope this gets fixed before 5.6 End-Of-Life.

Ubuntu, PHP 7, mySQL, still a problem. I'm sure other stacks (.NET/SQL Server/Java/Oracle) don't have this problem. This is now been around for almost 10 years? 

Please please, fix this.

...and PHP 5 has gone end-of-life with still no updates on this bug...

Which means that everyone using Microsoft SQL server on a *n*x system is either running an unsupported version, or unable to use most of the functionality of his database.

Nice article, Thanks for sharing..!!

DBLIB on unix cant accesses variables. Changing to windows or sqlsrv with the same code, works. I have a big client running procedure and i need to ge the return LOL

<?php

$database = "";
$server = "";
$user = "";
$pass="";


$str_host  = "dblib:host=" . $server;
$str_host .= ";dbname=" . $database;

try {
    $con = new PDO($str_host, $user, $pass);
    $con->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $con->exec("SET NOCOUNT ON");
} catch (Exception $ex) {
    print_r('Error: ' . $ex->getMessage());
    exit;
}

$comando = "DECLARE @mensagem varchar(20); SET @mensagem = 'Diogo Toscano'; SELECT @mensagem;";
$sth = $con->query($comando);
foreach ($sth as $row) {
    echo "<pre>";
    print_r ($row);
}

Expected result:
----------------
Array
(
    [] => Diogo Toscano
    [0] => Diogo Toscano
)


Actual result:
--------------