php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #68537 oci_bind_by_name() should provide unity length description
Submitted: 2014-12-02 08:32 UTC Modified: 2017-01-28 12:48 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: ikonta at yandex dot ru Assigned: sixd (profile)
Status: Assigned Package: OCI8 related
PHP Version: 5.4.35 OS: Gentoo GNU/Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ikonta at yandex dot ru
New email:
PHP Version: OS:

 

 [2014-12-02 08:32 UTC] ikonta at yandex dot ru
Description:
------------
After migrating to UTF8, database provides two-way semantics for text data types: byte (for single byte encodings is a synonim of char) and char.
http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT012

Length field in oci_bind_by_name() function forcely expect byte data size.
For now we should update documentation noting it.
For future development, ma be it is reasonable to add a modifier to switch between char and byte semantics.

SQL> CREATE TABLE EXAMPLE (
	MESSAGE		VARCHAR2(16 CHAR) NOT NULL
);

Oracle's client locale is:
NLS_LANG=RUSSIAN_RUSSIA.AL32UTF8

Test script:
---------------
<?php
  require_once("../inc/conn.inc");
  $conn = conn("UPO");
  $var = "тест-тест";

  $stid = oci_parse($conn, 'INSERT INTO EXAMPLE VALUES (:bv)');
  oci_bind_by_name($stid, ':bv', $var, 9);
  if (oci_execute($stid)) {
    echo ("insert OK");
    oci_free_statement($stid);
    oci_close($conn);
  }
  else
    echo ("insert failed");

?>

Expected result:
----------------
If client's locale is NLS_LANG=RUSSIAN_CIS.CL8ISO8859P5 properly encoded (translated from UTF8 back to ISO-8859-5) script works fine.

I expect the same for modern UTF8 locale.

Or at least proper description of issued function: what and how should be corrected.

Actual result:
--------------
If client is configured to use UTF8 locale, quoted script failes with ORA-01461 (can bind a LONG value only for insert into a LONG column) error.
Originally it was find for binding output variables for call of PL/SQL procedure.
In that case the error message was ORA-06525: Length Mismatch for CHAR or RAW data

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-12-02 22:25 UTC] sixd@php.net
-Assigned To: +Assigned To: sixd
 [2014-12-02 22:25 UTC] sixd@php.net
The PHP OCI8 bind lengths are bytes, as you noted.  The underlying Oracle OCI C library documents this appropriately "This size is always expected to be the size in bytes". (http://docs.oracle.com/database/121/LNOCI/oci16rel003.htm#LNOCI17140)

The PHP OCI8 doc needs to have similar wording. There are no plans to allow PHP OCI8 specify the size in characters.
 [2014-12-04 10:12 UTC] ikonta at yandex dot ru
> The PHP OCI8 bind lengths are bytes, as you noted.  The underlying
> Oracle OCI C library documents this appropriately "This size is
> always expected to be the size in bytes".
> (http://docs.oracle.com/database/121/LNOCI/oci16rel003.htm#LNOCI17140)

Not always.
Depending on NLS settings I can reproduce another result.
At least for currently used =dev-db/oracle-instantclient-basic-11.2.0.4 (and the same server).
Although, documentation may describe as it _should_ work, but not as it really works. Or it wasn't properly updated to correctly describe UTF8 handling in Oracle 11g yet.

If web-server is started in default locale, with also UTF8 charset:
NLS_LANG=AMERICAN_AMERICA.UTF8
the quoted test script succeed.
I.e. 9 chars, eight of which are two-byte length, are binded into variable with length limit 9 (unit, which should mean "byte").
 [2017-01-28 12:48 UTC] cmb@php.net
-Package: Documentation problem +Package: OCI8 related
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Nov 23 15:01:29 2024 UTC