Professional Web Applications Themes

#26407 [Fbk->Opn]: Result set fetching broken around transactions (OpenClient Error #155) - PHP Development

ID: 26407 User updated by: tvoigt at informatik dot tu-cottbus dot de Reported By: tvoigt at informatik dot tu-cottbus dot de -Status: Feedback +Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Linux (i686) & Solaris 8 PHP Version: 4.3.4 New Comment: All sample queries above execute perfectly well up to PHP version 4.3.3; on PHP-4.3.4 (and later devel snapshots) I'll get the OpenClient error message and those queries don't work. Both PHP versions are configured identically (on both machines, running Solaris or Linux). Nothing else has been altered. So whatever upsets OpenClient must have its origin in changed code ...

  1. #1

    Default #26407 [Fbk->Opn]: Result set fetching broken around transactions (OpenClient Error #155)

    ID: 26407
    User updated by: tvoigt at informatik dot tu-cottbus dot de
    Reported By: tvoigt at informatik dot tu-cottbus dot de
    -Status: Feedback
    +Status: Open
    Bug Type: Sybase-ct (ctlib) related
    Operating System: Linux (i686) & Solaris 8
    PHP Version: 4.3.4
    New Comment:

    All sample queries above execute perfectly well up to PHP version
    4.3.3; on PHP-4.3.4 (and later devel snapshots) I'll get the OpenClient
    error message and those queries don't work.

    Both PHP versions are configured identically (on both machines, running
    Solaris or Linux). Nothing else has been altered. So whatever upsets
    OpenClient must have its origin in changed code in PHP-4.3.4...

    Thanks and best regards,
    Thomas


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-12-01 11:57:39] net

    The other changes in the sources can not cause this.
    Are you sure this isn't openclient bug?
    Maybe you should ask them..


    ------------------------------------------------------------------------

    [2003-12-01 11:50:48] tvoigt at informatik dot tu-cottbus dot de

    Hi there!

    Thanks for your reply!

    Don't know if the mentioned bug/patch #23682 really interferes with my
    problem. The patch mainly skips unwanted (pseudo-)results in favor for
    getting the first real result set, right?
    Whereas I'm not *that* interested in fetching a particular result. But
    I have to depend on the database executing all of my queries up to the
    end.

    Because of query (II.) above, I assume that something deeper inside the
    query executing/fetching mechanism is broken: Query (II.) doesn't
    produce multiple result sets at all -- and the query fails with an
    OpenClient message.

    I'm not very familiar with C, but a 'diff' shows many changes in
    php_sybase_ct.c (4.3.3 -> 4.3.4) besides that patch from #23682: A lot
    of pointers became pointers of pointers and some additional Zend stuff
    moved in.

    The reported error message comes from the OpenClient library. Skipping
    some unwanted results should not bother the underlying database
    library, could it? Maybe there are some changes made in communication
    timing and/or execution order?
    Sybase's OpenClient doentation sadly is not very explicit about
    error #155, but some quite similar errors origin in wrong timing or
    execution order.


    Thanks again for your time!

    Best regards,
    Thomas

    ------------------------------------------------------------------------

    [2003-12-01 03:12:08] net

    No feedback was provided. The bug is being suspended because
    we assume that you are no longer experiencing the problem.
    If this is not the case and you are able to provide the
    information that was requested earlier, please do so and
    change the status of the bug back to "Open". Thank you.



    ------------------------------------------------------------------------

    [2003-11-25 14:47:32] net

    I would guess this is caused by fixing other bug:

    http://bugs.php.net/bug.php?id=23682

    Check that out..


    ------------------------------------------------------------------------

    [2003-11-25 10:40:09] tvoigt at informatik dot tu-cottbus dot de

    Description:
    ------------
    Hi there!

    When executing queries including a transaction and returning some
    result set PHP won't get any result handle, but the following
    OpenCLient error message (#155):

    "ct_results(): user api layer: external error: This routine cannot be
    called when the command structure is idle."

    Or in German:
    "ct_results(): Benutzer-API-Schicht: Externer Fehler: Aufruf der
    Routine nicht möglich, wenn die Befehlsstruktur nicht aktiv ist."

    My PHP-script continues to run (no crashes whatsoever), but the query
    has not been perfectly executed by Sybase.

    The error is reproducible with PHP-4.3.4 on quite different machines, a
    Sun UltraSparc running SunOS 5.8 and a i686 Linux box (Debian Woody
    3.0R1). Even tried PHP-4.3.5-dev (php4-STABLE-200311251230) and got the
    same error. Database is Sybase 11.9.2.

    Each query executes flawlessly via the isql frontend -- and did so up
    to PHP-4.3.3 (on the same machines, configured identically).


    PHP configuration (Linux box):
    ../configure \
    --with-regex=system \
    --with-apxs=/usr/local/apache/bin/apxs \
    --without-pear \
    --with-openssl \
    --with-zlib \
    --enable-calendar \
    --with-pfdlib=/usr/local/lib \
    --with-pgsql \
    --with-mysql=/usr/ \
    --with-sybase-ct=/opt/sybase-11.9.2 \
    --with-oci8=/usr/local/oracle \
    --with-oracle=/usr/local/oracle \
    --with-gd=/usr/local \
    --enable-gd-native-ttf \
    --with-jpeg-dir=/usr/local \
    --with-png-dir=/usr/lib \
    --with-ttf=/usr/local/lib \
    --with-freetype-dir=/usr/local/lib \
    --enable-exif \
    --enable-sigchild \
    --enable-track-vars

    PHP configuration (Sun machine):
    ../configure
    --with-apxs=/usr/local/apache-1.3.28/bin/apxs --disable-shared
    --enable-static --with-openssl=/usr/local/ssl
    --with-sybase-ct=/usr/local/Sybase --with-mysql=/usr/local/mySQL
    --with-pgsql=/usr/local/PostgreSQL --with-db4=/usr/local/BerkeleyDB-4.1
    --with-gd=/usr/local --with-jpeg-dir=/usr/local
    --with-png-dir=/usr/local --with-xpm-dir=/usr/local
    --with-freetype-dir=/usr/local --with-zlib=/usr/local --with-ftp
    --with-xml --enable-track-vars


    Reproduce code:
    ---------------
    /* I. fails: */
    begin transaction
    -- anything producing a result set here will fail;
    -- however, print or update statements will work
    select "foo"
    commit
    -- anything afterwards will fail, too


    /* II. fails: */
    begin transaction
    -- no result returned...
    update foobar set the_big_answer=42
    commit
    -- transaction is completed (correctly, indeed)...
    select "foo"
    -- ...but select statement afterwards fails, nonetheless


    /* III. works as expected: */
    select "foo"
    begin transaction
    -- do anything, even return a result set
    commit
    select "bar"
    -- or even do something useful like updates...


    Expected result:
    ----------------
    Sorry for all that SQL up there, but I've spend most of a day tracking
    my problem down and figuring out some hopefully useful examples.

    Yes, I know that Sybase queries returning multiple result sets are not
    completely fetchable by PHP (at most, one will get the first result set
    back).
    But I expect the whole query to be executed. In fact, I'm calling a set
    of stored procedures doing some quite important stuff, not just
    worshiping RFC 3092 ;-)


    Actual result:
    --------------
    Queries invoking statements that return fetchable result sets (via
    select, stored procedures) inside (I.) or AFTER a transaction block
    (II.) will fail. However, the first part of query II (the entire
    transaction block) is executed correctly, but PHP won't see no result
    handle. Other statements like print or update inside transactions work
    fine.

    I assume there is a bug (introduced with PHP-4.3.4) fetching the result
    set inside and around transactions, because similar queries with a
    fetchable result *before* a transaction block work as expected up to
    the end (III).

    As said before, all these queries work perfectly well up to PHP-4.3.3;
    simple workaround for me would be to insert some (fetchable) dummy
    selects on top of each transaction. But that's not the point of a bug
    report, is it?


    I very appreciate your help and all the work you do!

    Best regards and thanks in advance,
    Thomas Voigt


    ------------------------------------------------------------------------


    --
    Edit this bug report at http://bugs.php.net/?id=26407&edit=1
    tvoigt Guest

  2. #2

    Default #26407 [Fbk->Opn]: Result set fetching broken around transactions (OpenClient Error #155)

    ID: 26407
    User updated by: tvoigt at informatik dot tu-cottbus dot de
    Reported By: tvoigt at informatik dot tu-cottbus dot de
    -Status: Feedback
    +Status: Open
    Bug Type: Sybase-ct (ctlib) related
    Operating System: Linux (i686) & Solaris 8
    PHP Version: 4.3.4
    New Comment:

    Yes, we have Sybase's ctlib in production. We decided against FreeTDS
    here (for it crashed *way* too often).

    Here is the test output created by PHP/4.3.5RC2-dev (2004-01-26):
    http://www.informatik.tu-cottbus.de/~tvoigt/php/php_test_results_20040126.txt

    Thanks for your reply,
    Thomas


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-01-23 21:52:12] net

    Can neither reproduce with PHP/4.3.4 nor with current CVS. I'm using
    FreeTSD v.0.62 under FreeBSD/4.8-STABLE. Maybe this occurs with the
    Sybase-libraries only?

    Could you provide the ouput of

    $ make test TESTS=ext/sybase_ct/

    (execute in top source directory of a PHP checkout / snap)

    ------------------------------------------------------------------------

    [2003-12-02 10:25:11] tvoigt at informatik dot tu-cottbus dot de

    All sample queries above execute perfectly well up to PHP version
    4.3.3; on PHP-4.3.4 (and later devel snapshots) I'll get the OpenClient
    error message and those queries don't work.

    Both PHP versions are configured identically (on both machines, running
    Solaris or Linux). Nothing else has been altered. So whatever upsets
    OpenClient must have its origin in changed code in PHP-4.3.4...

    Thanks and best regards,
    Thomas

    ------------------------------------------------------------------------

    [2003-12-01 11:57:39] net

    The other changes in the sources can not cause this.
    Are you sure this isn't openclient bug?
    Maybe you should ask them..


    ------------------------------------------------------------------------

    [2003-12-01 11:50:48] tvoigt at informatik dot tu-cottbus dot de

    Hi there!

    Thanks for your reply!

    Don't know if the mentioned bug/patch #23682 really interferes with my
    problem. The patch mainly skips unwanted (pseudo-)results in favor for
    getting the first real result set, right?
    Whereas I'm not *that* interested in fetching a particular result. But
    I have to depend on the database executing all of my queries up to the
    end.

    Because of query (II.) above, I assume that something deeper inside the
    query executing/fetching mechanism is broken: Query (II.) doesn't
    produce multiple result sets at all -- and the query fails with an
    OpenClient message.

    I'm not very familiar with C, but a 'diff' shows many changes in
    php_sybase_ct.c (4.3.3 -> 4.3.4) besides that patch from #23682: A lot
    of pointers became pointers of pointers and some additional Zend stuff
    moved in.

    The reported error message comes from the OpenClient library. Skipping
    some unwanted results should not bother the underlying database
    library, could it? Maybe there are some changes made in communication
    timing and/or execution order?
    Sybase's OpenClient doentation sadly is not very explicit about
    error #155, but some quite similar errors origin in wrong timing or
    execution order.


    Thanks again for your time!

    Best regards,
    Thomas

    ------------------------------------------------------------------------

    [2003-11-25 14:47:32] net

    I would guess this is caused by fixing other bug:

    http://bugs.php.net/bug.php?id=23682

    Check that out..


    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://bugs.php.net/26407

    --
    Edit this bug report at http://bugs.php.net/?id=26407&edit=1
    tvoigt Guest

  3. #3

    Default #26407 [Fbk->Opn]: Result set fetching broken around transactions (OpenClient Error #155)

    ID: 26407
    User updated by: tvoigt at informatik dot tu-cottbus dot de
    Reported By: tvoigt at informatik dot tu-cottbus dot de
    -Status: Feedback
    +Status: Open
    Bug Type: Sybase-ct (ctlib) related
    Operating System: Linux (i686) & Solaris 8
    PHP Version: 4CVS, 5CVS
    New Comment:

    Hi there!

    Just applied your patch to a current snapshot
    (php4-STABLE-200402110830) and it works great! A brief test flight
    through our various Sybase applications completed without a hassle, so
    I consider that one done.

    Will this patch make it into PHP-4.3.5?

    Thanks again and best regards,
    Thomas


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-02-08 19:03:45] net

    Please see if the following patches work for you:

    * http://sitten-polizei.de/bug26407.diff
    (patch for CVS head - PHP5)
    * http://sitten-polizei.de/bug26407.4.diff
    (patch for Snapshot/4_3 branch)

    make test TEST=ext/sybase_ct is passed now with Sybase-libraries as
    well as with FreeTDS(download the new test.inc, it contains a fix for
    the "Sybase: Unable to update character set" warning).

    Please make sure I didn't break anything else.

    ------------------------------------------------------------------------

    [2004-02-08 18:02:53] net

    Have been able to reproduce w/ Debian and Sybase-Libraries.

    Bug was introduced when the patch in
    http://bugs.php.net/bug.php?id=23682 was committed.

    Am looking into a workaround.

    ------------------------------------------------------------------------

    [2004-02-08 17:20:39] net

    4.3.3 doesn't work as expected either. I took your output and diffed it
    against the expected one:

    thekidfriebes:~ > diff -u sybase_test_expected.out
    sybase_test_4_3_3.out
    --- sybase_test_expected.out Sun Feb 8 23:21:15 2004
    +++ sybase_test_4_3_3.out Sun Feb 8 23:20:12 2004
    -1,3 +1,4
    +Warning: sybase_connect(): Sybase: Unable to update character set. in
    /usr/src/php-4.3.3/ tests/ext/sybase_ct/test.inc on
    line 55
    bool(true) [/ref][/ref]
    begin transaction
    -7,14 +8,8
    commit
    -- anything afterwards will fail, too

    -<<< Return: resource
    -array(1) {
    - [0]=>
    - array(1) {
    - ["computed"]=>
    - string(3) "foo"
    - }
    -}
    +<<< Return: boolean
    +bool(true) [/ref][/ref]
    begin transaction
    -- no result returned...
    -31,7 +26,7
    select "bar"


    -Notice: sybase_query(): Sybase: Unexpected results, cancelling
    current in %s/test.inc on line %d
    +Notice: sybase_query(): Sybase: Unexpected results, cancelling
    current in /usr/src/php-4
    ..3.3/tests/ext/sybase_ct/test.inc on line 66
    <<< Return: resource
    array(1) {
    [0]=>


    ------------------------------------------------------------------------

    [2004-02-06 03:27:28] detoma dot alessandro at sea-aeroportimilano dot
    it

    Unfortunatly I don't know to help you, because I have a problem similar
    to your(failure to compile PHP4.3.4 with sybase 12.0).
    I notice however that you have compiled PHP4.3.4 with gdlib on
    solaris8; Could you say me which version you have used?
    Best regards,
    Alex

    ------------------------------------------------------------------------

    [2004-02-01 14:50:07] tvoigt at informatik dot tu-cottbus dot de

    Okay, done. It's my first bug report/'make test'-thing, but I'm just
    beginning to get it ;-)
    Thanks for your test case!

    Here's the content of bug26407.log (php4-STABLE-200401261030):
    http://www.informatik.tu-cottbus.de/~tvoigt/php/bug26407.log

    ....and to prove that everything was fine with php-4.3.3:
    http://www.informatik.tu-cottbus.de/~tvoigt/php/bug26407.log.php-4.3.3
    (Okay, there is a warning about the character set in sybase_connect,
    making this a "failed" test, too. But the actual test results are as
    expected. Maybe you want to adapt the test case?)

    If you are interested in the other sybase test's results, find the
    complete output here:
    http://www.informatik.tu-cottbus.de/~tvoigt/php/php_test_results_20040201.txt
    (#22403 testing failed for my dbo not allowing to create stored
    procedures in tempdb, sorry.)

    Thanks a lot,
    Thomas

    ------------------------------------------------------------------------

    The remainder of the comments for this report are too long. To view
    the rest of the comments, please view the bug report online at
    http://bugs.php.net/26407

    --
    Edit this bug report at http://bugs.php.net/?id=26407&edit=1
    tvoigt Guest

Similar Threads

  1. #39039 [NEW]: SSL: fatal protocol error when fetching HTTPS
    By david at acz dot org in forum PHP Bugs
    Replies: 3
    Last Post: October 5th, 12:38 AM
  2. Replies: 2
    Last Post: January 26th, 07:32 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139