[DBAL-496] "Undefined index" errors when using prepared statements Created: 16/Apr/13  Updated: 08/Sep/13  Resolved: 20/Apr/13

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Blocker
Reporter: Lukas Kahwe Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


Since a few days we are seeing errors like this in the Jackalope Doctrine DBAL test suite when using prepared statements:

Comment by Marco Pivetta [ 16/Apr/13 ]

First failure I can see is at https://travis-ci.org/jackalope/jackalope-doctrine-dbal/jobs/6347501 - is there any other relevant failure before that one?

Comment by Marco Pivetta [ 16/Apr/13 ]

The notice is thrown in in


Can be reproduced with parameters:


UPDATE phpcr_nodes SET sort_order = CASE CONCAT(
          (CASE namespace WHEN '' THEN '' ELSE ':' END),
        ) WHEN :name0 THEN :order0 WHEN :name1 THEN :order1 WHEN :name2 THEN :order2 WHEN :name3 THEN :order3 WHEN :name4 THEN :order4 ELSE sort_order END WHERE parent = :absPath


    ':absPath' => '/topic',
    ':name0' => 'page3',
    ':order0' => 0,
    ':name1' => 'page1',
    ':order1' => 1,
    ':name2' => 'page2',
    ':order2' => 2,
    ':name3' => 'page3',
    ':order3' => 3,
    ':name4' => 'page4',
    ':order4' => 4,


Comment by David Buchmann [ 17/Apr/13 ]

are we doing something wrong or is this a regression in dbal?

should we for now force an older version of doctrine-dbal? (this would be annyoing however, as we would run into version conflicts with doctrine-commons then i think)

Comment by Daniel Leech [ 17/Apr/13 ]

Seems this is caused by: https://github.com/doctrine/dbal/commit/64647f9e55749147b738cdba9378fa0401fadcbf

Comment by Fabio B. Silva [ 18/Apr/13 ]

I think the problem here is the ':' on the parameter key, which i'm not sure if are suported for DBAL.
Before #DBAL-488 it does not apply 'SQLParserUtils::expandListParameters' for parameters without types.

Comment by Benjamin Eberlei [ 20/Apr/13 ]

Reverted in master and 2.3

Comment by Fabio B. Silva [ 20/Apr/13 ]

Benjamin, Not sure if we should consider this one related to #DBAL-488.
It just show us another unsupported/unexpected behavior.

Actually, it will keep failing with any parameter key starting with ':' when types are given.

For instance :


SELECT * FROM foo WHERE bar = :bar


array(':bar'=>'Some String')


Comment by Lars Strojny [ 21/Apr/13 ]

Here is a successor for the fix from PR 301, @Fabio, could you test that with your code base: https://github.com/doctrine/dbal/pull/309

Generated at Fri Oct 09 02:50:30 EDT 2015 using JIRA 6.4.10#64025-sha1:5b8b74079161cd76a20ab66dda52747ee6701bd6.