php - PDO returning empty property name -

i'm having strange issue pdo_odbc , pdo::fetch_obj (and pdo::fetch_class) results in following error message:

php fatal error:  cannot access empty property 

here's code:

$dbh = new pdo("odbc:foo");  $sth = $dbh->query("   select rolename   dbc.allrolerights   databasename = 'bar' ");  $result = $sth->fetch(pdo::fetch_obj); 

the foo dsn, reference, teradata datasource using tdata.so driver, provided tdodbc package.

i believe happening because field name (as returned odbc query) blank when pdo calls zend_api.h:object_init_ex() instantiate stdclass object. if switch pdo::fetch_lazy , var_dump() row, following:

object(pdorow)#3 (2) {   ["querystring"]=>   string(95) "   select rolename   dbc.allrolerights   databasename = 'bar' "   [""]=>   string(30) "fnar                          " } 

which seems up. i've tried several different pdo attribute combinations , bunch of different angles work around problem. 1 solution fetch associative array , pass class constructor. however, doesn't work frameworks , orms using pdo::fetch_class directly, behind scenes.

i want add other fetch methods seem right thing, example, pdo::fetch_named:

array(1) {   ["rolename"]=>   string(30) "fnar                          " } 

i'm looking can put in pdo dbh or sth definition, or in odbc.ini or odbcinst.ini datasource or driver, resolve issue. thank in advance.

update: odbc_fetch_object() (i.e. not pdo) works great same exact everything. wanted mention it. there doesn't seem serious issues php, unixodbc, or odbc driver. it's in pdo code. time open bug report... opened

$dbh = odbc_connect("foo", null, null)   or die(odbc_error_msg());  $sth = odbc_exec($dbh, "   select rolename   dbc.allrolerights   databasename = 'bar' ");  $result = odbc_fetch_object($sth); var_dump($result); 

and output:

object(stdclass)#1 (1) {   ["rolename"]=>   string(30) "fnar                          " } 

update 2: situation continues grow more , more bizarre. can pdo::fetch_lazy , see blank column name seen in var_dump() above, if try access property name (e.g. $result->rolename), works! these fetch methods doing differently of them can access field names, , others cannot?

side-by-side comparisons of odbc traces ("working" cf. "not working") shows no differences (other different pointer addresses). pdo::fetch_bound works both numbered , named columns. pdo::fetch_into object rolename property not.

your question describes 2 problems:

1. why objects cannot created properties having empty-string names when using pdo::fetch_obj, apparently can when using other methods?

   as documented under internal structures , implmentation in php internals book, "dynamic properties" (i.e. object's member variables not declared in class definition, rather created @ runtime) implemented hash table.

   if 1 wishes populate newly instantiated standard object bunch of properties held in hash table, 1 can point object's properties variable @ existing hash table—php's object_and_properties_init() function, called by odbc_fetch_object(), does that without performing sanity checking on table's keys. consequently, 1 can instantiate object strange property names (such empty string).

   on other hand, if 1 has instantiated object , needs set property value (whilst preserving others exist), 1 must copy value object's hash table—php's zend_std_write_property() method, handles action standard objects, does that having first performed sanity check on property name. consequently, 1 cannot add property strange name (such empty string) existing object.

   this discrepancy in sanity-checking between 2 approaches appears, mind, bug: restrictions on dynamic property names should enforced irrespective of method such properties created. whether strange names of sort should allowed (and therefore sanity checking should removed latter method), or disallowed (and therefore sanity checking should added former method), decision shall leave php developers.

   how pdo fit this?

   pdostatement::fetch() first prepares destination results stored , iterates on columns storing each field in turn: imagine in order simplify codebase, each fetch style can implemented within same structure. however, mean when called using pdo::fetch_obj style (and both pdo::fetch_class , pdo::fetch_into, have observed), an object instantiated first , its properties populated later. consequently, strange property names (such empty string) result in observed failure.

   the other fetch styles have tried don't experience same problem because:

   • pdo::fetch_bound fetches variables specified previous call pdostatement::bindcolumn(), php never attempts write property having empty name;

   • pdo::fetch_lazy skips whole shebang , things similar manner odbc_fetch_object() above.

   similarly, array-based fetch styles won't suffer similar problems because empty-string keys valid in hash tables.

2. why pdo thinks column names in odbc recordset empty strings?

   the answer less obvious me.

   we saw earlier that, populate properties, pdo uses stmt->columns[i].name property name. should have been correctly filled @ an earlier point, when pdo_stmt_describe_columns() was called. function in turn had called driver's describer method each column in resultset: in case of pdo_odbc, that's odbc_stmt_describe() indeed assign value field.

   so, looks fine on php side. interesting know whether the call driver's sqldescribecol() function correctly populated column name buffer provided third argument: 1 imagines not, suggest problem lies in odbc driver itself. mentioned you're using teradata: sure using same driver both pdo_odbc (which isn't working) , ext/odbc (which is)?

   in particular, teradata document under extension level functions:

   by default, sqldescribecol , sqlcolattribute return column name instead of teradata column title. if application wants odbc driver teradata return column title instead of actual column name, option use column names in teradata odbc driver options dialog box must not selected dsn used, or set dontusetitles = no on unix os.

   returning column title instead of actual column name can cause problems applications, such crystal reports, because expect column name , not column title.