mysql_num_rows(): supplied argument is not a valid MySQL result resource in

[D-MO]

Empezado por dec

Hola,

Yo he visto utilizar para esto la función "mysql_error()", puesto que retorna el mensaje de error de MySQL, o una cadena vacía, si no hay error alguno. No sé si servirá o no decirlo aquí ahora.

Que tal David, ¿Como te vá?... La función la utilizas para lo que yó he dicho, o haces referencia a lo que dijo román?

Empezado por richy08

D-Mo la idea de que le usuario pueda meter sentencias sql es un poco extraña no te parece , si de por si ya es bastante teidoso estar cuidandote de la inyeccion de sql para que le darias a un usuario oportunidad de que te ejecute en una aplicacion sentencias sql , y la funcion de mysql_error no la habia visto le echare unvistazo mil gracias.

Bueno, como expresé arriba, es poco común pero puede darse el caso, phpMyAdmin y/o TurboDBAdmin por ejemplo.

Saludos

Saludos.

[richy08]

Empezado por D-MO

Que tal David, ¿Como te vá?... La función la utilizas para lo que yó he dicho, o haces referencia a lo que dijo román?

Bueno, como expresé arriba, es poco común pero puede darse el caso, phpMyAdmin y/o TurboDBAdmin por ejemplo.

Saludos

Saludos.

Si en esos casos tienes mucha razon

[roman]

Empezado por dec

Yo he visto utilizar para esto la función "mysql_error()", puesto que retorna el mensaje de error de MySQL, o una cadena vacía, si no hay error alguno.

Empezado por D-MO

Que tal David, ¿Como te vá?... La función la utilizas para lo que yó he dicho, o haces referencia a lo que dijo román?

Soy una persona autocontradictoria Vi el comentario de dec y pensé mencionar un punto en contra, pero luego vi el de D-MO y me di cuenta que yo mismo ya lo había mencionado.

En fin, lo que quiero comentar, y de esto me parece que dec está muy al tanto, es que mysql_error hay que usarla con cuidado. Es decir, vale dejar el mensaje durante las pruebas pero no ya "en producción" puesto que la información puede proporcionar detalles acerca de la estructura de nuestras tablas.

// Saludos

[dec]

Hola,

Empezado por Román

En fin, lo que quiero comentar, y de esto me parece que dec está muy al tanto, es que mysql_error hay que usarla con cuidado. Es decir, vale dejar el mensaje durante las pruebas pero no ya "en producción" puesto que la información puede proporcionar detalles acerca de la estructura de nuestras tablas.

Bueno. Yo lo que he visto es que se comprueba el resultado de dicha función, pero no que se muestre al usuario, sino que, precisamente, si esa función retorna algo que no sea una cadena vacía, puede darse por hecho que ha habido un error en MySQL, en la consulta que lleváramos a cabo, por ejemplo. Pero de ahí a mostrar el mensaje de error al usuario hay un trecho. Y sí, estoy contigo, es decir, el usuario no debería ver ningún mensaje de error de este tipo o de PHP. De hecho utilizo una función inspirada por cierto código de Emilio, que pongo por aquí, por si le sirve a alguien:

Código PHP:

function SetErrorLevel(){
  if($_SERVER['SERVER_ADDR'] != '127.0.0.1'){
    error_reporting(0);
    ini_set('display_errors', 0);
    ini_set('error_reporting', 0);
  }else{
    error_reporting(E_ALL);
    ini_set('display_errors', 1);
    ini_set('error_reporting', E_ALL);
  }
  return true;
} 


Como digo, vengo usando esta función en mis últimos proyectos o cosas que hago con PHP. Y la función viene a averiguar si el "script" se ejecuta en "local" o no, y, si efectivamente no se ejecuta en "local", se hace por ocultar cualquier tipo de error de PHP al usuario. Lo que hay que hacer, evidentemente, es llamar a esa función al comienzo de nuestros "scripts", de modo que se establezca el nivel de error adecuado.

PD. Se admiten críticas y mejoras para la función "SetErrorLevel()", puesto que las incorporaría a mis proyectos "activos".

PD 2. Nótese que "SetErrorLevel()", en caso de que el "script" se ejecute en "local", establece el nivel de reportes de error más exigente, es decir, se mostrarán todos las "noticias", "advertencias" y "errores" propiamente dichos, pero, esto es lo suyo cuando estamos probando una aplicación en "local", puesto que nosotros sí debemos hacer algo respecto de los mensajes de error correspondientes.

[roman]

Por eso decía yo que estabas al tanto de ello aunque no me había percatado de la forma de usar la susodicha función. Pero es algo raro ¿no? Es decir ¿por qué en lugar de poner

Código PHP:

$conexion = mysql_connect(....);
if (!$conexion)
{
  bla, bla, bla
} 


pondríamos?

Código PHP:

$conexion = mysql_connect(....);
if (!mysql_error())
{
  bla, bla, bla
} 


No sé, se me hace curioso usar una función haciendo caso omiso de su valor (o casi)

// Saludos

[dec]

Hola,

Bueno. Lo cierto es que cuando ví usar la función "mysql_error()" (creo que en el propio manual de PHP, pero, no sé si en algún comentario al mismo) recuerdo, en todo caso, que era para averiguar si una consulta SQL retornaba algún error, no se podía llevar a cabo. Para la conexión, como tú has hecho, yo también prefiero (quizás sólo por costumbre) comprobar si el correspondiente "link" está disponible o no.

Desde luego incluso en el caso de consultas SQL podría bastarnos con no obtener resultados, por ejemplo, para saber que "algo fue mal", pero, ya digo, he visto usar la función de marras para comprobar si había algún error en la última consulta SQL y por eso lo he referido aquí. No sé, por mi parte no veo problema en usar el resultado de la función, puesto que esta no retornará "nada" si no hay errores, pero,... quizás pensándolo de otro modo no sería lo suyo hacer esto.

Es decir, podríamos comprobar si no obtenemos resultados, por ejemplo, y, si es que los pensábamos obtener, comprobar entonces el resultado de la función "mysql_error()". No sé. Creo que es según cómo enfoques el asunto... pero quizás no sea muy elegante... no sé...