2012-01-17 8 views
9

Esto me ha estado molestando durante las últimas dos (cerca de tres) horas, y solo se manifiesta en una plataforma.¿Por qué esta fila solo aparece cuando se ejecuta PHP en Windows y no en CentOS?

Aquí es el esquema de una tabla SQL:

CREATE TABLE cache (url     TINYTEXT, 
        data    MEDIUMTEXT, 
        retrieval_timestamp INT, 
        ttl     INT) 

Ahora, mi código PHP utiliza el conductor SQLite DOP para crear un archivo de base de datos en el disco. La instrucción SQL anterior se ejecuta y la tabla se crea. Hasta ahora todo bien - todas mis máquinas de prueba ejecutan con éxito esa declaración.

A continuación, inserto los datos en la tabla; de nuevo, todas las máquinas insertan los datos sin error. Debido a que SQLite almacena la base de datos en un archivo, simplemente puedo abrirla en SQLite Database Browser y verificar que los datos estén insertados.

Aquí es donde ocurre el problema: No puedo recuperar los datos en una máquina CentOS con PHP 5.2.

Este es el código PHP que estoy usando (y tener en cuenta que funciona en PHP 5.3 en Windows):

$statement = $this->database->prepare('SELECT data FROM cache WHERE url = ? AND retrieval_timestamp + ttl >= ?'); 

$statement->bindValue(1, $url); 
$statement->bindValue(2, time(), PDO::PARAM_INT); 

$statement->execute(); 

En el equipo de CentOS, el código anterior se ejecuta sin devolver ningún error. Pero en lugar de devolver las filas esperadas (que las otras máquinas devuelven la misma consulta misma) no obtengo nada, no filas. Si cambio SELECT data a SELECT data, retrieval_timestamp + ttl, puedo ver los resultados de la expresión y compararlos con la marca de tiempo actual a mano, y los datos realmente satisfacen la condición, por lo que debe devolverse en los resultados.

Si quito la segunda parte de la cláusula WHERE, se devuelve los datos esperados, pero por supuesto, que contradice el objetivo de la mesa :)

¿Qué estoy haciendo mal?


Actualización: se pone más raro - cuando se utiliza en lugar de queryprepare y especificar los parámetros de forma manual, funciona (en la máquina CentOS). Por lo tanto, parece ser un problema con las declaraciones preparadas.

Aquí está el archivo de SQLite: http://dl.dropbox.com/u/31080052/test.sqlite
Ésta es la consulta que estoy corriendo en él:

SELECT data FROM cache WHERE url = 'c' AND retrieval_timestamp + ttl >= 1326780275 

Respuesta

0

Más o menos una puñalada en la oscuridad: ¿Ha intentado cambiar los signos de interrogación a " :valores"? es decir:

$statement = $this->database->prepare('SELECT data FROM cache WHERE url = :url AND retrieval_timestamp + ttl >= :rval'); 
$statement->bindValue(":url", $url); 
$statement->bindValue(":rval", time(), PDO::PARAM_INT); 

$statement->execute(); 
+0

Sí, me temo que sí, sin ninguna diferencia. –

0

No he mirado en el archivo de SQLite que ha conectado pero comprueba las versiones de controlador/extensión que está utilizando - se han añadido ciertas características en SQLite desde una versión a la siguiente. Verifique las secciones sobre migraciones en el enlace de documentación a continuación. Estoy bastante seguro de que las diferencias de SO no harán que SQL deje de funcionar.

http://www.sqlite.org/docs.html

1

Ha comprobado si los relojes están sincronizados en los dos equipos?

+0

Sí, estoy seguro de que los dos relojes están sincronizados (he verificado dos veces), aunque realmente no debería haber ninguna diferencia ya que estoy ejecutando una consulta idéntica con los mismos datos. –

1

dos posibilidades que vienen a la mente:

  • es instalar el CentOS de 32 bits? ¿Estás intentando leer/escribir marcas de tiempo que no encajan en una int de 32 bits?
  • ¿Las marcas de tiempo son negativas? Tuvimos un problema hace mucho tiempo en el que Debian parecía no admitir marcas de tiempo negativas y mover un proyecto desde Slackware causó todo tipo de problemas debido a eso.
+0

Lamentablemente, no creo que ninguna de esas opciones sea válida, ya que el problema solo se manifiesta cuando utilizo 'bindValue()' y no cuando inserto el mismo valor directamente en la consulta. –

Cuestiones relacionadas