Problemas con insert =S

[Mayra_Ale]

Buenas, tengo un problema al insertar un registro en una de las tablas de mi base de datos... Lo estoy haciendo de la misma manera como inserto otras tablas pero en esta no se me agregan los datos... La unica diferencia es q ésta tiene 3 index y un autoincrement... no veo cual es el problema si le estoy pasando los datos bien, los mando a imprimri con "echo" y me imprime lo q es... no se q hacer! porfa ayuda!!. De antemano, gracias =)

$sql="insert into hab(ID_Hab,ID_Serv,ID_Via) values($hab,'".$serv[$j]."',$id_via)";
if(mysql_query($sql,$link)){
echo "Hab Ingresada Correctamente... ";
}

[quimfv]

... La unica diferencia es q ésta tiene 3 index y un autoincrement...

Revisa la definición de los indices, si son UNIC puede que estes intentando insertar valores repetidos y luego es normal y bueno que no los inserte.

El campo autoincrement no debes pasarlo en la sentencia INSERT ya lo llena el solo...

Con la información que nos das no te puedo decir nada más...

Quim

[jurena]

Mayra_Ale,

comprueba también esto, el hecho de que añades con comillas un dato que probablemente es numérico, me refiero a $serv[$j], al parecer un dato procedente de un array; si el campo donde lo cargas en la base MySQL es INT o de naturaleza numérica, no te carga ni ese dato ni ningún otro dato de la consulta.
De modo que si se trata de un campo numérico, prueba con esto:
sql="insert into hab(ID_Hab,ID_Serv,ID_Via) values($hab,{$serv[$j]},$id_via)";
if(mysql_query($sql,$link))
...
A ver si hay suerte

[gnzsoloyo]

Craso error, jurena, MySQL es un motor que funciona contextualmente. Si quieres ingresar un VARCHAR en un DATETIME, TIME, INT, o BLOB, MySQL lo ingresará, siempre y cuando el contenido del campo o variable se ajusten al tipo de datos esperable.
Esto es:
Puedes ingresar un string con comillas en un DATETIME, siempre y cuando respetes el formato '0000-0-00- 0:00:00'.
También convertirá a INT un valor entrante como '1023', pero te indicará "data truncated' si lo intentas entrar como '1023.45'.
El problema no es el uso de comillas en el contenido de la sentencia de inserción, sino qué comillas uses (" y ' tienen usos diferentes en MySQL), y si el dato entrante se corresponde con el campo donde se ingresará.
Esto lo veo mucho usando ODBC y VB.NET. De hecho, para evitar problemas de conversión, los DATETIME los suelo enviar siempre convertidos a string entre apóstrofes ('). Jamás he tenido problemas de error de conversión ni de inserción.

Un medio para ver qué es lo que puede estar pasando es: Recuperar el string completo que se está generando para el insert que se envía a MySQL, y probarlo directamente en el MySQL Query Browser o phpmyadm para ver qué error está indicando.

[jurena]

gnzsoloyo,
mi desconocimiento de los aspectos técnicos me han llevado tal vez a no expresarme correctamente, o simplemente a equivocarme: lo que quiero decir es que el problema lo causa PHP no la sintaxis de MySQL, pues puede cargarse perfectamente desde PHPMyAdmin poniendo las comillas. Sin embargo, si tratas de cargar mediante una consulta lanzada con PHP y dependiendo del tipo de comillas en un campo INT, puede darte problemas. A mí me los ha dado, y de hecho el resultado era que no cargaba ningún otro dato de dicha consulta.
La verdad que no sé la razón técnica y tal vez es un error mío. Si es así, te agradecería mucho, gnzsoloyo, que nos dijeras la mejor forma de hacerlo para evitar errores.
Gracias de antemano

[gnzsoloyo]

Jurena:
Un error mío: Me estaba olvidando del uso que PHP le da a las comillas. Perdón por ello.

Yendo al tema, en algunos casos he tenido algunos problemas al crear los strings necesarios para ciertas consultas, sea desde VB.net o bien desde otros lenguajes. Especialmente cuando hay que manipular las comillas o caracteres especiales de cualquier tipo.

Un caso ejemplar es cuando se requiere que el string entre con las comillas dentro del mismo("), en otros casos el problema estuvo dado por la conversión de los separadores de decimales, ya que por default en MySQL es el punto, pero dependiendo de la región declarada, esto hacía entrar comas(,) donde debía haber puntos... y la coma es separador de campos de MySQL... Imagínate el problema que causaba esto.

Una de las soluciones que encontré en algunos foros y manuales, era usar la función Char() de VB al construir la sentencia, lo que generaba estructuras del tipo:

Código:

sString = "INSERT INTO Tabla1(Campo1) VALUES(" + Char(39) + _
"valor" + Char(39)

o bien en VB.net

Código:

sString = "INSERT INTO Tabla1(Campo1) VALUES(" + _
ControlChars.Quote + "valor" + ControlChars.Quote

Habría que probar que tal funciona la función CHR() en este caso, y si puede ayudar a manejar mejor el problema.

De todos modos hago hincapié en una prueba que propuse al final, y que a veces es algo tosca pero te permite controlar errores que no entran en la categoría de Exception.

Por un lado, en vez de construir la sentencia dentro de la misma función de llamada al query, es mejor cargarla en una variable primero, de modo que puedas revisarla menjor.
Después, previo a enviarla a MySQL, sería bueno mostrarla para ver si la sintaxis se está construyendo bien. Ocasionalmente se olvidan algunos espacios y ciertos valores se encadenan indebidamente, dando lugar a errores casi imperceptibles a simple vista.
Después, si la consulta falla, sería bueno tomar el string construido y probarlo directamente en la base por medio de uina interfase del tipo MySQL Query Browser (de MySQL), o bien myphpAdmin. Sugiero el primero porque es nativo de MySQL. AL ejecutar la sentencia, puede aparecer cuál es el verdadero problema.

[jurena]

gnzsoloyo,
no ha sido error tuyo (permíteme que te tutee), sino que yo no me expliqué bien y te confundí, pues no precisé, como hubiera sido conveniente, que el problema estaba en la sintaxis de PHP. Creo que en el caso de la sintaxis propuesta, si Mayra_Ale prueba a hacerlo sin comillas, tal vez obtenga el resultado deseado.
Por lo demás, muchísimas gracias por una explicación tan útil para todos nosotros, máxime para mí, un hombre de letras. Llevo poco tiempo en este foro MySQL, pero tus aclaraciones y explicaciones me parecen siempre de lo más profesional, técnico y acertado. Sigue así, pues los que queremos aprender, estaremos siempre atentos a lo que escribes.

Jesús