0

I have problem while mapping DB2 Table with Doctrine 2. Application exists for a long time and for strange reason there was a "£" special char added in front of some columns names.

Ex : £ADRB1

While checking documentation, it appreared that this is something Doctrine does not like very much. By the way, connection is made through a ODBC driver :/ which I cannot change.

Entity column is configured this way :

/**
 * @ORM\Column(name = "`£ADRB1`", type="string", length=38, options={"default":""})
 */
protected $ADRB1;

Error is

SQLSTATE[HY090]: Invalid string or buffer length: 0 [IBM][System i Access ODBC Driver]Invalid string or buffer length. (SQLPrepare[0] at /patched-php-src-5.5.7/php-5.5.7/ext/pdo_odbc/odbc_driver.c:206)

While trying to fetch result with simple queryBuilder.

Is there any possibility to be able to get it work with Doctrine 2 ?

Many thanks !

Benjamin Ghenne
  • 91
  • 1
  • 1
  • 10
  • Can you please execute the query through another method than Doctrine2, to verify CRPence's statement that this issue is not Doctrine-related? – lxg May 17 '15 at 21:12

1 Answers1

1

I know nothing about Doctrine2, but if the origin for the issue has anything to do with the column name [which seems at least somewhat tenuous given the error implies nothing about a column name], then probably the issue is related to the name of the column [at what is presumably an IBM i as the server] having the first character defined using the EBCDIC code-point 0x5B.

While that EBCDIC code-point x'5B' is valid to represent the variant Dollar Sign character in some code pages [a valid but discouraged character, just like the @; see: Using @ on Variable Names], the Pound Sterling Sign character [ASCII code-point 0xA3] sent from an ASCII client may not get translated to the EBCDIC code-point x'5B'. The outcome depends on how the server is configured for the Code Page, and quite likely the character would translate to the EBCDIC code-point 0xB1; a code-point that is unlikely to represent a valid character for an SQL identifier such as a column name.

So if the client can refer to the column name having specified the first character as the $ character instead of as the £ character, then when the expected\proper character conversion from ASCII to EBCDIC occurs, the server will correctly see the column name as the expected name; i.e. will in effect, see the characters $ADRB1 in EBCDIC [hex:5BC1C4D9C2F1] as translated from the ASCII characters $ADRB1 [hex:2441445231] rather than the likely\undesirable outcome instead whereby the server in effect will see the characters £ADRB1 in EBCDIC [hex:B1C1C4D9C2F1] as translated from the ASCII characters £ADRB1 [hex:A341445231].

p.s. The tag DB2i is defined in the wiki as the DB2 for IBM i and the tag DB2 is defined in the wiki as the DB2 family, but the tag ibm-db2 has no definition https://stackoverflow.com/tags/ibm-db2/info, so if the server is IBM i with the DB2 for i as the database, then perhaps the DB2i is a better [or additional] choice for tagging this topic.?

Community
  • 1
  • 1
CRPence
  • 1,259
  • 7
  • 12
  • FWiW, if the column name is the potential issue, the SQL can be used to CREATE VIEW on the server to name explicitly the columns from the SELECT, each without any variant characters. Presumably if that VIEW can be accessed without error, but not the TABLE, then that gives more credence to the idea that the column-name is an origin for the issue. – CRPence May 18 '15 at 03:43