se puede consultar y insertar a la vez?

[bellleti]

tengo una tabla mensajes que cuando se lee un mensaje pongo el campo leido a 1 es por eso que nose si se puede hacer todo junto.. o tengo ke hacerlo pos separado...

Código PHP:

  //la consulta....
 
 $sql = "SELECT m.missatge, m.data, m.titol, m.idorigen ,m.usersend, g.id, g.usuari      FROM missatges m ,granges g 
                        WHERE g.usuari like '$usuari'
                            and m.idorigen = g.id
                        and m.llegit=0"; 
   

luego quiero actualizar la tabla y poner un 1 en leido..como se hace???


.... asi no creo no? xD :P
and INSERT INTO missatges (idorigen,titol, missatge, llegit, data, usersend) VALUES ('$usuari','$titolmis' 'm.missatge', 1,'m.data' ,'$userenviat')";

[GatorV]

Lo que debes de hacer es un UPDATE sobre tus datos para cambiar la columna de leido a 1.

Saludos

[bellleti]

Iniciado por GatorV

Lo que debes de hacer es un UPDATE sobre tus datos para cambiar la columna de leido a 1.

Saludos

se puede hacer el update en la misma consulta? o se tiene que hacer en otra por separado??

$sql = "SELECT m.missatge, m.data, m.titol, m.idorigen ,m.usersend, g.id, g.usuari
FROM missatges m ,granges g
WHERE g.usuari like '$usuari'
and m.llegit=0
and m.data = '$datamis'
and m.titol = '$titolmis'";
-----) //and update missatges set llegit =1

[gnzsoloyo]

existen en este tipo de operaciones una serie de restricciones de consistencia:
1. No se puede leer y borrar un registro en la misma operación. Sería como tratar de cortar la rama sobre la que estás parado en un árbol.
2. No se puede actualizar el mismo registro que se está leyendo. MySQL no puede saber a priori si el dato que estás modificando no es el mismo que usó para encontrar el registro.
3. No puedes hacer un JOIN sobre la misma tabla para realizar operaciones de DDL o DML. Esas operaciones pueden dar lugar a inconsistencias en el proceso.
4. No se pueden implementar operaciones de UPDATE sobre la misma tabla en un TRIGGER. Por las mismas razones más la básica: estarías haciendo un ciclo recursivo eterno.

Si lo meditas, las restricciones salen de la lógica propia característica de las operaciones invocadas. Algunas de estas no aparecen en los manuales o en los tutoriales porque son restricciones elementales en programación en todos los lenguajes, por lo que son conocidas por los programadores (vox populi).
De todos modos no está de más aclararlas. A veces a uno se le olvidan.

En esencia, lo que tratas de lograr es hacer la menor cantidad de operaciones para obtener los mayores resultados. Eso no siempre se puede lograr, y de todos modos, cuando trabajas con datos, es mejor hacer las cosas en forma ortodoxa, porque un diseño de consulta mal realizado puede significar meses de datos perdidos...
Es mejor hacer las operaciones por parte.

[bellleti]

Iniciado por gnzsoloyo

existen en este tipo de operaciones una serie de restricciones de consistencia:
1. No se puede leer y borrar un registro en la misma operación. Sería como tratar de cortar la rama sobre la que estás parado en un árbol.
2. No se puede actualizar el mismo registro que se está leyendo. MySQL no puede saber a priori si el dato que estás modificando no es el mismo que usó para encontrar el registro.
3. No puedes hacer un JOIN sobre la misma tabla para realizar operaciones de DDL o DML. Esas operaciones pueden dar lugar a inconsistencias en el proceso.
4. No se pueden implementar operaciones de UPDATE sobre la misma tabla en un TRIGGER. Por las mismas razones más la básica: estarías haciendo un ciclo recursivo eterno.

Si lo meditas, las restricciones salen de la lógica propia característica de las operaciones invocadas. Algunas de estas no aparecen en los manuales o en los tutoriales porque son restricciones elementales en programación en todos los lenguajes, por lo que son conocidas por los programadores (vox populi).
De todos modos no está de más aclararlas. A veces a uno se le olvidan.

En esencia, lo que tratas de lograr es hacer la menor cantidad de operaciones para obtener los mayores resultados. Eso no siempre se puede lograr, y de todos modos, cuando trabajas con datos, es mejor hacer las cosas en forma ortodoxa, porque un diseño de consulta mal realizado puede significar meses de datos perdidos...
Es mejor hacer las operaciones por parte.

muchas gracias!!! otra pequeña question.. se puede hacer prefijos en uptades tambien? como asi....

UPDATE granges g,
missatges m SET m.llegit =1 WHERE g.usuari LIKE 'genero' AND m.llegit =0 AND m.DATA = '27-01-2009'

gracias

[gnzsoloyo]

se puede hacer prefijos en uptades tambien?

No me queda claro a qué te refieres con prefijos. Pareciera que te refieres a los ALIAS de tablas y campos. Si eso es lo que quieres decir, si. dentro de una sentencia DML como es UPDATE corren los mismos usos en el manejo de nombres que para un SELECT o un INSERT o un DELETE.
Estas cosas las puedes encontrar en el manual oficial(13.2. Sentencias de manipulación de datos ), e incluso en cualquier manual de SQL, porque pertenecen al estándar de SQL (ANSI SQL 1999:2000)