When I try to use SQLSRV_FETCH_BOTH for SQL-statement about "select ... from [viewName]" result set contained superfluous fields( duplicates and other fields from joined tables). Other types of fetchType work correctly.
(No version information available, might only be in Git)
sqlsrv_fetch_array — Returns a row as an array
$stmt
[, int $fetchType
[, int $row
[, int $offset
]]] )Returns the next available row of data as an associative array, a numeric array, or both (the default).
stmt
A statement resource returned by sqlsrv_query or sqlsrv_prepare.
fetchType
A predefined constant specifying the type of array to return. Possible
values are SQLSRV_FETCH_ASSOC
,
SQLSRV_FETCH_NUMERIC
, and
SQLSRV_FETCH_BOTH
(the default).
A fetch type of SQLSRV_FETCH_ASSOC should not be used when consuming a result set with multiple columns of the same name.
row
Specifies the row to access in a result set that uses a scrollable cursor.
Possible values are SQLSRV_SCROLL_NEXT
,
SQLSRV_SCROLL_PRIOR
, SQLSRV_SCROLL_FIRST
,
SQLSRV_SCROLL_LAST
, SQLSRV_SCROLL_ABSOLUTE
and,
SQLSRV_SCROLL_RELATIVE
(the default). When this parameter
is specified, the fetchType
must be explicitly defined.
offset
Specifies the row to be accessed if the row parameter is set to
SQLSRV_SCROLL_ABSOLUTE
or
SQLSRV_SCROLL_RELATIVE
. Note that the first row in
a result set has index 0.
Returns an array on success, NULL
if there are no more rows to return, and
FALSE
if an error occurs.
Example #1 Retrieving an associative array.
<?php
$serverName = "serverName\instanceName";
$connectionInfo = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$conn = sqlsrv_connect( $serverName, $connectionInfo );
if( $conn === false ) {
die( print_r( sqlsrv_errors(), true));
}
$sql = "SELECT FirstName, LastName FROM SomeTable";
$stmt = sqlsrv_query( $conn, $sql );
if( $stmt === false) {
die( print_r( sqlsrv_errors(), true) );
}
while( $row = sqlsrv_fetch_array( $stmt, SQLSRV_FETCH_ASSOC) ) {
echo $row['LastName'].", ".$row['FirstName']."<br />";
}
sqlsrv_free_stmt( $stmt);
?>
Example #2 Retrieving a numeric array.
<?php
$serverName = "serverName\instanceName";
$connectionInfo = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$conn = sqlsrv_connect( $serverName, $connectionInfo );
if( $conn === false ) {
die( print_r( sqlsrv_errors(), true));
}
$sql = "SELECT FirstName, LastName FROM SomeTable";
$stmt = sqlsrv_query( $conn, $sql );
if( $stmt === false) {
die( print_r( sqlsrv_errors(), true) );
}
while( $row = sqlsrv_fetch_array( $stmt, SQLSRV_FETCH_NUMERIC) ) {
echo $row[0].", ".$row[1]."<br />";
}
sqlsrv_free_stmt( $stmt);
?>
Not specifying the fetchType
or explicity using the
SQLSRV_FETCH_TYPE
constant in the examples above will
return an array that has both associative and numeric keys.
If more than one column is returned with the same name, the last column will take precedence. To avoid field name collisions, use aliases.
If a column with no name is returned, the associative key for the array element will be an empty string ("").
When I try to use SQLSRV_FETCH_BOTH for SQL-statement about "select ... from [viewName]" result set contained superfluous fields( duplicates and other fields from joined tables). Other types of fetchType work correctly.
Note that using a foreach loop on an array built by sqlsrv_fetch_array without specifying either SQLSRV_FETCH_NUMERIC or SQLSRV_FETCH_ASSOC will go through both the associative and numeric keys in the array. This can be a problem if you're trying to write to a CSV file for example; you'll end up with double data.
Note that while the docs say to avoid SQLSRV_FETCH_ASSOC when dealing with result sets where multiple fields have the same name, there are cases when this is perfectly valid to do.
Consider the following query:
SELECT * FROM a INNER JOIN b ON a.id = b.id
For any row, if you fetch NUMERIC you'll get a field for both a.id and b.id, which probably isn't very useful.
If you fetch ASSOC, you'll get one field for "id", and given that it's always the same in both tables (because your query insists it is so), you're not at risk of losing anything.
If you're generating output based on an unknown number of fields, the ASSOC behavior might be preferred.