ORA-01461 on windows

You are facing one of those problems that makes me happy about using Oracle instead of MySQL:

if you look at "./modules/system/system.install" line 1406 you can see that actually the core create the filename field as 255 char long:

....
$schema['system'] = array(
'description' => "A list of all modules, themes, and theme engines that are or have been installed in Drupal's file system.",
'fields' => array(
'filename' => array(
'description' => 'The path of the primary file for this item, relative to the Drupal root; e.g. modules/node/node.module.',
'type' => 'varchar',
'length' => 255,
'not null' => TRUE,
'default' => '',
),
....

You are trying to insert a value of 1072 charcaters, so the value exceed the column length...
You are probably right when you say that on mysql this will "work"... Or to be more detailed i should say the insert works and it works really bad!! Try to create a table with a column of 255 charcaters in mysql and now try to insert a value of 1072 characters inside it...
You will see that the value is inserted... but silently truncate at 255 chars!!!! So actually on mysql you installation works because a file path is truncated and when you will try to use this functionality from the system table it will fail...
See this blog post for details:
http://www.suspekt.org/2008/08/18/mysql-and-sql-column-truncation-vulner...
You should use the STRICT_ALL_TABLES mysql option.

So please file a bug on the drupal project for that... or tell me if you are not going to do that so i will. ;)

Meanwhile, to solve your installation problem simply change this "./modules/system/system.install" line 1406 to a longer field, say 2000...

Are you using your patch for E_STRICT warnings when doing this test?

Actually i've reinstalled a fresh version of drupal-7.0-alpha3 with the last -dev of my driver and it simply installs without any issue...

Please try without the E_STRICT flag and without patches if you where...

In the query method of database.inc you can find 2 commented syslog... If you uncomment those lines you can trace your statements in the error_log of your httpd. It would be interesting to know what value you are trying to insert.

It definitely looks like you are using the -dev release.. Or there is some kind of windows related issue.

Let's try to find it.

Ok, i'm going to try the alpha4 this night.. i'm actually using the alpha3...
Looks like SAVEPOINTs for rollback have been added in the last release.

Ok found it. I just commited a new version of -dev fixing the ref value passing in query.inc.
I also fixed the savepoint issue. No "savepoint release" in oracle.. But savepoints are safely overwritten
so it all works fine by simply ignoring the release command.

Be sure to download the repackaged version.. because the drupal.org packaging system is asynchronous and takes
some time to rebuild..

@jurgenhaas thank you for traking down the problem... I hope you can support this driver anytime soon.. just keep looking around and submitting patches.

Are you using alpha4 with last -dev oracle driver? Can you attach your oracle/query.inc?

I cannot reproduce it. Can you install the attached patch to debug values in the syslog and give me back the last "value: " you find in the error_log before the ORA-01461 error.

This error should not exists because the driver prevents it translating values > 4000 chars in BLOBs (DatabaseConnection_oracle::cleanupArgValue method).

...attaching the patch

Actually the last entry in your log is the famous batch table update... The strange thing here is that the cleanupArgValue function should translate this long value to a BLOB automagically. This is not happening and so the statement fails. It looks like a PHP issue with variable passed by reference... Can you test this php with your installation please?

  $string= "my";

  echo '<br>'.is_string(&$string);
  echo '<br>'.strlen(&$string);

    $strings= "my";

 foreach ($strings as $key => &$str)
 {
   echo '<br>'.is_string($str);
   echo '<br>'.strlen($str);
}

It would be useful if you can upgrade to PHP 5.2.12.

ooops... retry this please:

  $string= "my";

  echo '<br>'.is_string(&$string);
  echo '<br>'.strlen(&$string);

    $strings= array("my");

foreach ($strings as $key => &$str)
{
   echo '<br>'.is_string($str);
   echo '<br>'.strlen($str);
}

Ok, in your SQL the

"###value:"

is produced after cleanupArgValue in the query.inc like in my patch?

If yes can you debug a bit more the cleanupArgValue method:

  public function cleanupArgValue($value)
  {
              syslog(LOG_ERR,"######cleanup");

            if (is_string($value))
            {
              syslog(LOG_ERR,"######string length: ".strlen($value));
              if ($value=='')
                return ORACLE_EMPTY_STRING_REPLACER;
              elseif (strlen($value)>ORACLE_MAX_VARCHAR2_LENGTH)
                return $this->writeBlob($value);
              else
                return $value;
            }
            else
              return $value;
  }

yes and is 1323 charcaters.. So no blob translation is needed (the batch column should be 4000 chars long so no error should came up)... Forgive the debug... the cleanupArgValue is working correctly..

Can u try logging the $batch['id'] value please?

can you please try reinstalling (install.php) with the attached query.inc? I think is a problem linked some way to PHP reference / how the PDO_OCI driver use those references in your configuration. If the attached file will not work i'm going to setup a windows machine with php 5.2.9 to try out your config so that i can debug it locally. On my installations the problem simply do not occur.

I am seeing the same or a similar issue with 7 alpha 4 and the latest -dev of the oracle driver:

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://d7a43.localhost:8084/install.php?q=install.php&profile=minimal&locale=en&id=1&op=do StatusText: OK ResponseText: {"status":true,"percentage":"100","message":"Completed 12 of 12.\u003cbr \/\u003eInstalled \u003cem\u003eMinimal\u003c\/em\u003e module."}Uncaught exception thrown in shutdown function.PDOException: UPDATE "BATCH" SET batch=:db_update_placeholder_0 WHERE (bid = :db_condition_placeholder_0) e: SQLSTATE[HY000]: General error: 1461 OCIStmtExecute: ORA-01461: can bind a LONG value only for insert into a LONG column (ext\pdo_oci\oci_statement.c:146) args: Array ( ) in _batch_shutdown() (line 516 of C:\Documents and Settings\vmiliano\My Documents\Sites\drupal-7.0-alpha4\includes\batch.inc).

I am testing both regular and minimal installs of Drupal 7 alpha 4 under Oracle XE and Zend Server (I couldn't get the Acquia Stack working with OCI) on Windows XP. This error appears right after step 10 of 12, which installs Blocks.

Continuing to the error page shows no errors, but the Drupal index.php home page shows this:

Error message
DatabaseTransactionNoActiveException: in DatabaseConnection->rollback() (line 870 of C:\Documents and Settings\vmiliano\My Documents\Sites\drupal-7.0-alpha4\includes\database\database.inc).

I'am actually installing XAMPP on a windows vm to reproduce the problem...
Just to check have you all used the Univ version of oracle xe ? (The one with utf8 support) If not you should.

Ok... good news, i was able to reproduce it on windows.. tomorrow i'm going to check it.

I guys looks like you (on windows) are facing this PDO_OCI bug:
http://bugs-beta.php.net/bug.php?id=40787&edit=1

I remember i was having the same problem on linux but at some point of php 5.2.x (where x > 9)
it disappeared.

So to make it work meanwhile they solve it you can simply resize the:
define('ORACLE_MAX_VARCHAR2_LENGTH',4000);
to read
define('ORACLE_MAX_VARCHAR2_LENGTH',1332);
at the top of database.inc.

This will probably slowdown a bit the driver because more values will be transalted to blobs, but actually is the only way to make it work on windows i think.

My conf:
XAMPP 1.7.3 (yes finally i tried to use the more recent php that should include the more recent pdo_oci but nothing changed)
Drupal 7 alpha 4
Oracle driver last -dev + 1332 hack (as said)

So with this hack it installs smoothly on my test env. Once the PDO_OCI maintainers solve the problem you can simply bring the value back to 4000 and existing values will be preserved while new values will be handled faster.

cheers,
andrea

Thanks! Drupal 7 alpha 4 appears to install cleanly for me on Oracle XE on Windows, now.

I've run into additional issues with contrib modules like devel, but I will open separate tickets for those.

@vmiliano remeber you can use oracle exception_queries global variable from settings.php to translate wrong statements on the fly:

a quick example:

$GLOBALS['oracle_exception_queries']= array(
'/^SELECT q.*, COUNT\(s.sqid\) AS subqueues FROM {nodequeue_queue} q LEFT JOIN {
nodequeue_subqueue} s ON q.qid = s.qid WHERE q.qid IN \((.*?)\) GROUP BY q.qid$/
' => 'SELECT q.*, (SELECT COUNT(s.sqid) FROM {nodequeue_subqueue} s WHERE q.qid = s.qid) AS subqueues FROM {nodequeue_queue} q WHERE q.qid IN (\1)','/^SELECT s.*, COUNT\(n.position\) AS count FROM {nodequeue_subqueue} s LEFT JOI
N {nodequeue_nodes} n ON n.sqid = s.sqid WHERE s.qid IN \((.*?)\) GROUP BY s.sqid$/' => 'SELECT s.*, (SELECT COUNT(n.position) FROM {nodequeue_nodes} n WHERE n.sqid = s.sqid) AS count FROM {nodequeue_subqueue} s WHERE s.qid IN (\1)'
);

is a PDO_OCI bug.