Problem with pdo FetchField with sqlsrv

[diogotoscano]

On method FetchField changed:
if (isset($arr['native_type']) && $arr['native_type'] <> "null") {
$o->type = $arr['native_type'];
}
else {
$o->type = adodb_pdo_type($arr['pdo_type']);
}

to:

    if (isset($arr['sqlsrv:decl_type']) && $arr['sqlsrv:decl_type'] <> "null") {
        $o->type = $arr['sqlsrv:decl_type'];
    }
    elseif (isset($arr['native_type']) && $arr['native_type'] <> "null") {
        $o->type = $arr['native_type'];
    }
    else {
        $o->type = adodb_pdo_type($arr['pdo_type']);
    }

DUe to sqlsrv the type come in the index "sqlsrv:decl_type"

[mnewnham]

According to This page, the PHP type is returned in the 'native_type' field. Are you saying that the value in that field is incorrect? could you give a sample of code where the data is being returned inappropriately please. Also what version of PHP, what version of ADOdb, platform, driver etc.

[diogotoscano]

Not incorrect, but inaccurate. As you can see at the documentation:
driver:decl_type Specifies the SQL type used to represent the column value in the database. If the column in the result set is the result of a function, this value is not returned by PDOStatement::getColumnMeta.

The index native_type can't tell if a type is varchar, nvarchar, char or nchar. Always come with "string".

As you can see in my teste attached

mssql.zip

The output:
Array
(
[flags] => 0
[sqlsrv:decl_type] => int
[native_type] => string
[table] =>
[pdo_type] => 2
[name] => codigo
[len] => 10
[precision] => 0
)

Array
(
[flags] => 0
[sqlsrv:decl_type] => varchar
[native_type] => string
[table] =>
[pdo_type] => 2
[name] => teste1
[len] => 222
[precision] => 0
)

Array
(
[flags] => 0
[sqlsrv:decl_type] => nvarchar
[native_type] => string
[table] =>
[pdo_type] => 2
[name] => teste2
[len] => 222
[precision] => 0
)

Array
(
[flags] => 0
[sqlsrv:decl_type] => nchar
[native_type] => string
[table] =>
[pdo_type] => 2
[name] => teste3
[len] => 2
[precision] => 0
)

But we need to know the difference between varchar and nvarchar to change the SQL to protect with N''

[dregad]

@mnewnham you targeted this at 5.21, yet you committed cb5f1c7 to 5.20.5 branch - should I change the milestone ?

[mnewnham]

No, I'm (amazingly) ahead of schedule on this

[dregad]

I'm not sure I understand what you mean by that. I see 2 sets of fixes

• cb5f1c1 in 5.20.5 branch
• pull request Add support for setAttribute via setConnectionParameter in ADOdb #247 #249 references this issue (see commit be670e4), does not have a formal target milestone set, but wants to update master branch so that de facto makes it 5.21

So IMO either the former is the fix and the milestone of this issue should be is 5.20.5, or the proper fix is the latter, in which case shouldn't cb5f1c1 not be applied in 5.20.5.

Please clarify