PEAR Bug Search Results

DB: Bug 16117 [Open] MSSQL escape doesn't take into account trailing backslashes

eddie at omegaware dot com — 2009-04-17T19:58:13+00:00

DB Bug
Reported by urkle
2009-04-17T19:58:13+00:00
PHP: 5.2.9 OS: CentOS 5 Package Version: 1.7.13

Description:
------------
when inserting a string that has a trailing backslash followed by a new line (either CR or LF or BOTH) the backslash and the new line is stripped by SQL Server.   

Instead an EXTRA check needs to be made to escape the trailing backslash with another backslash.  (ie.. C:\\ instead of C:\) but ONLY if it appears at the end of a line.  escaping backslashes anywhere else in the input will cause the backslash to be added twice.

Documentation: http://support.microsoft.com/kb/164291
(NOTE that the document is slightly incorrect in that you do NOT replace \ with \\  Only once set of new line sequences is needed.. Just simply added an extra \ before the trailing \ is all that is needed.)

Test script:
---------------
$db = DB::connect("mssql://server:1433/database");
$db->query("CREATE TABLE #temp (f1 TEXT)");
$db->query("INSERT INTO #temp VALUES ("
     .$db->quoteSmart("Test C:\\\nHello")
    .")");
echo $db->getOne("SELECT f1 FROM #temp");
$db->query("DROP TABLE #temp");

Expected result:
----------------
echoing 

C:\
Hello

Actual result:
--------------
echoing

C:Hello

DB: Bug 15481 [Analyzed] float values are quoted

ml at kiewel-online dot ch — 2009-01-15T09:50:55+00:00

DB Bug
Reported by ukiewel
2009-01-01T21:25:24+00:00
PHP: 5.2.8 OS: Linux Package Version: 1.7.13

Description:
------------
Integer values are passed correctly to the database backend (DB2 via ODBC) float values are being quoted. That quote is imho a bug. Float values have also passed unquoted to the database backend.



Test script:
---------------
 $dbh->query($update, array(2, 3.5, 4.5, 24));

Expected result:
----------------
correct statemend passed to the db with unquoted numeric values

Actual result:
--------------
integers are unquoted, floats are quoted:

from the DB2 trace:
UPDATE policy SET spam_tag_level = 2, spam_tag2_level = '3.5', spam_kill_level = '4.5' WHERE id = 48

DB: Bug 15142 [Open] Commands out of sync , without reason!

kmak at ccf dot auth dot gr — 2009-02-07T15:32:19+00:00

DB Bug
Reported by kmak
2008-11-24T08:39:36+00:00
PHP: 5.2.6 OS: gentoo Package Version: 1.7.13

Description:
------------
While i do free the DB_Result object that return from a query, i still get an out of sync message when i try to make a new query. That only happens after a procedure call query.

i have mysql 5.0.60-r1

Thank you.

Test script:
---------------
    require('my_db_conf.php');
    require('DB.php');


    $db_link = DB::connect(MAIN_DB_URL);

    if (PEAR::isError($db_link))
    {
            echo "Error connecting: ".$db_link->getMessage()."\n";
            exit(1);
    }

    $db_link->setFetchMode(DB_FETCHMODE_ASSOC);

    // Set names to utf8
    $res =& $db_link->query("set names utf8");

    if($res === DB_OK) echo "res is DB_OK no free is required...\n";

    if(PEAR::isError($res) || $res !== DB_OK)
    {
        echo "Error seting utf names...\n";
        exit(1);
    }

    //here i call the stored procedure...
    $query = "call myStoredProc()"; //it does a select only inside

    $res =& $db_link->query($query);
    if(PEAR::isError($res))
    {
        echo "Error executing query:".$query."\n";
        exit(1);
    }

    //here i free the results of the stored procedure
    $res->free();


    //here i call something else...
    $query = "SELECT * FROM table1";
    $res =& $db_link->query($query);
    if(PEAR::isError($res))
    {
        echo "Error executing query:".$query."\n";
        echo "Debug info!:".$res->getDebugInfo()."\n";
        exit(1);
    }

    $res->free();
    $db_link->disconnect();

Expected result:
----------------
res is DB_OK no free is required...

Actual result:
--------------
res is DB_OK no free is required...
Error executing query:SELECT * FROM table1
Debug info!:SELECT * FROM table1 [nativecode=2014 ** Commands out of sync; you can't run this command now]

DB: Bug 15115 [Verified] __wakeup passes the wrong params to connect

jonty at jonty dot co dot uk — 2009-02-07T15:18:29+00:00

DB Bug
Reported by jonty
2008-11-21T12:10:50+00:00
PHP: 5.2.5 OS: Linux Package Version: 1.7.14RC1

Description:
------------
The __wakeup method in DB/common.php passes the ->options array to ->connect(). ->connect() takes a boolean ($persistent), not an array of options.

This means that any deserialised DB connection will always reconnect in persistent mode.

Attached is a patch to fix this, written in a manner that should deal with both old and new style calls to ->connect().

DB: Bug 14603 [Open] Wrong replace in last_query

marciodick at yahoo dot com — 2008-09-19T09:56:31+00:00

DB Bug
Reported by mds123
2008-09-05T13:59:06+00:00
PHP: 5.1.6 OS: linux Package Version: 1.7.13

Description:
------------
It replaces bindN in all string, replacing also bindNN when it should not.

Test script:
---------------
Correction to apply to oci8 driver:

@@ -668,11 +668,12 @@ class DB_oci8 extends DB_common
             }
             if (!@OCIBindByName($stmt, ':bind' . $i, $data[$key], -1)) {
                 $tmp = $this->oci8RaiseError($stmt);
                 return $tmp;
             }
-            $this->last_query = str_replace(':bind'.$i, $this->quoteSmart($data[$key]), $this->last_query);
+            //$this->last_query = str_replace(':bind'.$i, $this->quoteSmart($data[$key]), $this->last_query);
+            $this->last_query = substr_replace($this->last_query, $this->quoteSmart($data[$key]), strpos($this->last_query, ':bind'.$i), strlen(':bind'.$i));
             $i++;
         }
         if ($this->autocommit) {
             $success = @OCIExecute($stmt, OCI_COMMIT_ON_SUCCESS);
         } else {

DB: Bug 14271 [Open] oci8: freePrepared() does not free _prepared_queries array

falk dot herrmann at bike24 dot net — 2008-07-01T08:34:54+00:00

DB Bug
Reported by falk
2008-07-01T08:34:54+00:00
PHP: 5.2.6 OS: Linux Package Version: 1.7.14RC1

Description:
------------
The Method freePrepared() in oci8.php does not free the prepared SQL queries. Add "unset($this->_prepared_queries[(int)$stmt]);"

DB: Bug 13676 [Open] db2connection from PHP

sobhan dot maddineni at logica dot com — 2008-04-14T09:52:30+00:00

DB Bug
Reported by sobhanmaddineni
2008-04-14T09:17:44+00:00
PHP: 4.4.0 OS: Linux Package Version: 

Description:
------------
My application is connecting to DB2 7.1 version earleir using db2connect, now the database has upgraded to 8.0, now we are getting problems in accessing the application.
PHP Version:4.4, PEAR version:1.50.2.18

I here by attached a sample file which i am using, please provide me the solution for this problem if you already know it.

Thanks!

Test script:
---------------
setFetchMode(DB_FETCHMODE_ASSOC);
foreach ($sql_tests as $sql) {
   debug ("executing: $sql");
   $res =& $db->query($sql);
   if (DB::isError($res)) {
      debug_db($res);
      continue;
   }
   if (DB_OK != $res) {
      while ($row =& $res->fetchRow()) {
         $row = lowerCase($row);
         debug($row);
      }
   }
   debug ("done");
}
$db->disconnect();
?>


Expected result:
----------------
29

Actual result:
--------------
Standard Message: DB Error: unknown error
Standard Code: -1
DBMS/User Message: SELECT count(*) FROM db.ccrest [nativecode=36001 [IBM][CLI Driver][DB2] SQL0243N SENSITIVE cursor "SQL_CURSH200C4" cannot be defined for the specified SELECT statement.  SQLSTATE=36001]
DBMS/Debug Message: SELECT count(*) FROM db.ccrest [nativecode=36001 [IBM][CLI Driver][DB2] SQL0243N SENSITIVE cursor "SQL_CURSH200C4" cannot be defined for the specified SELECT statement.  SQLSTATE=36001]

DB: Bug 13537 [Open] limitQuery always returns the same result set

ruifilipe dot reis at gmail dot com — 2008-03-30T05:29:56+00:00

DB Bug
Reported by rui
2008-03-30T05:29:56+00:00
PHP: 5.2.3 OS: linux Package Version: 1.7.13

Description:
------------
limitQuery always returns the same result set, the output of  var_dump($db->last_query); is:

string(38) "select id, nome, data_nasc from testes"

var_dump($data->limit_from); and var_dump($data->limit_count);
both return NULL

I'm using unixodbc + freetds driver to access a MSSQL database.

Test script:
---------------
function whatever($db, $from, $count) {

$sth =& $db->limitQuery("select id, nome, data_nasc from testes", $from, $count);

while ($row =& $data->fetchRow()) {
        echo "";
        echo "" . $row[0] . "" . $row[1] . "" . $row[2] . "";
        echo "";
}
}

whatever($db, 0, 20);
whatever($db, 40, 20);
whatever($db, 60, 20);


Expected result:
----------------
1, whatever, whatever
2, whatever, whatever
(...)
20, whatever, whatever
21, whatever, whatever
22, whatever, whatever
(...)
40, whatever, whatever
41, whatever, whatever
42, whatever, whatever
(...)
60, whatever, whatever

Actual result:
--------------
1, whatever, whatever
2, whatever, whatever
(...)
20, whatever, whatever
1, whatever, whatever
2, whatever, whatever
(...)
20, whatever, whatever
1, whatever, whatever
2, whatever, whatever
(...)
20, whatever, whatever

DB: Bug 13366 [Open] nextId does not correctly handle $ondemand parameter with PostgreSQL 8.2

2008-03-10T16:39:33+00:00

DB Bug
Reported by davidn
2008-03-10T16:39:33+00:00
PHP: 5.2.3 OS: Linux Package Version: 1.7.13

Description:
------------
Test script is very simple:
Just try to use the nextId function with PostgreSQL 8.2:

$db->nextId("toto", true);

The sequence "toto_seq" should not exist.
Pear should try to create the sequence.

Actually, the test made in nextId in pgsql.php line 682 is:

if ($ondemand && DB::isError($result) &&
                $result->getCode() == DB_ERROR_NOSUCHTABLE) {

But for some reason, $result->getCode() == DB_ERROR instead of $result->getCode() == DB_ERROR_NOSUCHTABLE, so the test is never accepted and the sequence never created.

Suggested step to correct: replace line 682 with:

if ($ondemand && DB::isError($result) &&
                ($result->getCode() == DB_ERROR_NOSUCHTABLE || $result->getCode() == DB_ERROR)) {


Best regards,
David.

DB: Feature/Change Request 13193 [Open] 'auto_increment' feature in tableInfo() for sqlite

2008-02-25T04:01:51+00:00

DB Feature/Change Request
Reported by rpuchkovskiy
2008-02-25T04:01:51+00:00
PHP: Irrelevant OS:  Package Version: 1.7.13

Description:
------------
Sqlite supports auto-incremented columns (integer primary key is auto-incremented), but current implementation of tableInfo() does not return this information.
I suggest adding following lines

            // integer primary key is autoincremented...
            if (strtoupper($type) == "INTEGER" && $id[$i]['pk']) {
                $flags .= 'auto_increment ';
            }

below these lines

            if ($id[$i]['dflt_value'] !== null) {
                $flags .= 'default_' . rawurlencode($id[$i]['dflt_value']);
            }

in tableInfo() method of DB/sqlite.php. This will return 'auto_increment' feature for auto-incremented columns.

DB: Bug 12673 [Open] Return error when execute statement INSERT INTO [TABLE1] SELECT FROM [TABLE2]

antonio dot musarra at romcad dot it — 2007-12-12T09:37:58+00:00

DB Bug
Reported by amusarra
2007-12-12T09:37:58+00:00
PHP: 4.4.7 OS: SUSE Enterprise Linux Server 10 Package Version: 1.7.13

Description:
------------
Running query type INSERT INTO [Customers] SELECT * FROM [New Customers] on the Informix database (Driver IFX.php) back error SQLCODE = 0. The query syntax is correct and supported by Informix.

Test script:
---------------
// Connect to db
...

// Prepared query
$stm = $db->prepare("INSERT INTO import_sap_log_old SELECT * FROM import_sap_log WHERE id=?");
$data = array($MAX_ID);
$res = $db->execute($s, $data);

....

DB: Bug 12546 [Open] pgsql commit() doesn't commit in non-autocommit mode

canobix at gmail dot com — 2007-11-29T04:09:02+00:00

DB Bug
Reported by canobi
2007-11-29T04:09:02+00:00
PHP: 4.3.10 OS: Linux Package Version: 1.7.13

Description:
------------
When trying to commit a transaction by calling commit() 
method of a DB object that has autoCommit set to false, 
the changes aren't commited. The current workaround I'm 
using is by executing a query with a 'commit;' statement, 
and then calling commit() (to reinitialize any transaction 
specific fields in the DB object).

Test script:
---------------
Connect as usual, then:
$dbh -> autoCommit ( false );
$result = $dbh -> query ( do an insert );
$dbh -> commit ( );
$dbh -> disconnect ( );


Expected result:
----------------
Expecting to see the inserted row in the database. The 
version of Postgres used is 7.4.

Actual result:
--------------
The inserted row is not present in the database.

DB: Bug 11993 [Assigned] ifx: cannot execute select on TEXT_FIELD

argenti dot m at tin dot it — 2007-11-28T03:19:13+00:00

DB Bug
Reported by argentim
2007-09-06T06:46:03+00:00
PHP: 5.2.4 OS: win_xp Package Version: 1.7.12

Description:
------------
Unable to execute a select on a table with TEXT fields
It doesn't work on Informix 9.40.uc3/esql 3.00.tc1 db
while it works on MySQL 5.0

Its a bug or something else to look/configure?


Test script:
---------------
after db connection:

$select="select  from table where row_id=1";
$result=$db->query($select);
if (DB::isError($result)) die($result->getMessage());

will return on ifx: "DB Error: unknown error"