SQL - Registros que no se tienen en cuenta en una consul

 
Vista:

Registros que no se tienen en cuenta en una consul

Publicado por Gary (6 intervenciones) el 09/05/2010 00:13:59
Hola a todos!!

A ver si me podéis ayudar porque me esta sucediendo una cosa de lo más extraña y para la que no tengo explicación.

Os explico el tema: Mi objetivo era realizar una consulta SQL para rellenar con su resultado un DataGrid y, dado que no soy ningún experto en SQL, preparé unos registros de prueba para comprobar que la consulta funcionaba correctamente.

En la consulta trabajo con dos tablas las cuales tienen un campo fecha.
Mi consulta recibe como parametro una fecha que introduce el usuario.
Necesito que la consulta devuelva los registros en los que la fecha coincide con la primera tabla, pero que la fecha de la segunda tabla no coincida con la fecha introducida por el usuario, siempre que los registros sean del mismo socio.

Ejemplo:

El socio1 tiene un registro en la tabla1 con fecha 1/1/10 y otro registro en la tabla2 con la misma fecha.

El socio2 tiene un registro en la tabla1 con fecha 1/1/10 y otro registro en la tabla2 con la fecha 30/1/10.

El socio3 tiene un registro en la tabla1 con fecha 15/10/09 y otro registro en la tabla2 con la fecha 1/1/10.

Si el usuario introduce como parametro la fecha 1/1/10 me deberia devolver solo el registro del socio2, ya que este es el único que coincide la fecha introducida por el usuario con la fecha del registro de la tabla1 y no tiene un registro con la misma fecha en la tabla2. Por esta misma razón el socio1 no aparecería, ya que este tiene un registro con la misma fecha en la tabla2 y el socio3 tampoco ya que la fecha de la tabla1 no coincide con la introducida como parametro.

A continuación expongo como he planteado la consulta:

SELECT DISTINCT HISTORIAL_ALQ.num_socio AS [N Socio], HISTORIAL_ALQ.fecha_devolucion AS [Fecha Devolucion], HISTORIAL_ALQ.num_parte AS [N Parte], HISTORIAL_ALQ.cantidad_servida AS Cantidad, HISTORIAL_ALQ.cod_ropa AS [Cod Ropa], HISTORIAL_ALQ.quien_dev AS [Quien devuelve?], HISTORIAL_ALQ.notas AS Notas, HISTORIAL_ALQ.num_socio AS Socio FROM (HISTORIAL_ALQ INNER JOIN HISTORIAL_LLV ON HISTORIAL_ALQ.num_socio = HISTORIAL_LLV.num_socio) WHERE (HISTORIAL_ALQ.fecha_devolucion = #" & fecha & "#) AND (HISTORIAL_ALQ.num_socio NOT IN (SELECT num_socio FROM HISTORIAL_LLV HISTORIAL_LLV_1 WHERE (fecha_devolucion = #" & fecha & "#)))"

Tras varias pruebas consegui la sentencia SQL citada y tras los test con los registros de prueba que habia preparado veo que funciona correctamente.

Cual es mi sorpresa al continuar introduciendo registros para hacer más tests y descubro que la consulta solo funciona con los registros que tenía previamente pero no con los nuevos q introduzco, es como si los ignorará...

He probado con una copia de la BD en blanco y tampoco funciona con los registros q introduzco pero, por el contrario si copio y pego los antiguos registros de la anterior BD en la nueva si funciona correctamente.

Estoy trabajando con una BD de Access.

Espero haberme explicado con claridad y encontrar a alguien que sepa como solucionar esto porque para mi es un misterio.

Gracias por adelantado, un saludo!!
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
sin imagen de perfil
Val: 806
Bronce
Ha mantenido su posición en SQL (en relación al último mes)
Gráfica de SQL

RE:Registros que no se tienen en cuenta en una con

Publicado por Leonardo Josue (1173 intervenciones) el 10/05/2010 16:30:26
Gary: esta es la tercera vez que pones el mismo problema en este foro. En las ocasiones anteriores ya se te han dado respuestas, pero hasta ahora no has contestado si los códigos te han servido o no. el día 24/04/2010 publicaste un post y te fue respondido por Leandro y por un servidor. Sigue sin comentarios de tu parte. el día 02/05/2010 publicaste un post y te fue contestado por el compañero Rolando... también está si respuesta de tu parte.

Te pediría que antes de comenzar una nueva pregunta te tomes cinco minutos para responder a las personas que te han contestado en otras ocasiones. Si la solución que ahí se presenta no resuelve tu problema pues eso debes comentarlo, decir qué salió mal para poder ayudarte, y sinceramente me parece una falta de respeto que ni siquiera te tomes el tiempo para agradecer a las personas que han tratado de ayudarte.

Saludos
Leo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

RE:Registros que no se tienen en cuenta en una con

Publicado por Gary (6 intervenciones) el 10/05/2010 19:12:06
Hola Leo.

Lo cierto es que tienes razón y por ello te pido disculpas.

Siento mucho no haber respondido a los post, ya que debería haberlo hecho, pero la razón de que haya posteado de nuevo mi consulta es que aunque es sobre el mismo tema la consulta no es exactamente igual ya que habia progresado algo entre la primera y esta última.

Aprovecho para responderte. Basicamente es lo que ya te he comentado. Probé con la consulta que me proponias y continuaba sin obtener el resulatdo esperado. Continué investigando y consegui la consulta que muestro en este post, que como veras es muy diferente (consta de una subconsulta y de un NOT IN) y con esa consulta me ocurre lo que ya comento, que con los registros de prueba si que va pero con los nuevos que introduzco no.

Te pido de nuevo disculpas.

Un saludo!
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 806
Bronce
Ha mantenido su posición en SQL (en relación al último mes)
Gráfica de SQL

RE:Registros que no se tienen en cuenta en una con

Publicado por Leonardo Josue (1173 intervenciones) el 11/05/2010 16:36:42
Hola Gary:

¿Cuál es el problema con la consulta?, ¿marca algún error o no obtienes los datos esperados?

Estuve analizando lo que publicaste aun no entiendo muy bien la lógica que quieres aplicar. Por ejemplo, tengo duda acerca si la relación entre las tablas HISTORIAL_ALQ e HISTORIAL_LLV es 1 a 1, 1 a muchos (1-n) o muchos a muchos (m-n). Pongamos el siguiente ejemplo: supongamos que la tabla HISTORIAL_ALQ tiene los siguientes datos

Socio|Fecha|ID
1|01/01/2010|HISTORIAL_ALQ_1
2|01/01/2010|HISTORIAL_ALQ_2
3|02/01/2010|HISTORIAL_ALQ_3

ahora bien, supongamos que la tabla HISTORIAL_LLV tiene los siguientes datos:

Socio|Fecha|ID
1|02/01/2010|HISTORIAL_LLV_1
1|03/01/2010|HISTORIAL_LLV_2
1|04/01/2010|HISTORIAL_LLV_3
2|01/01/2010|HISTORIAL_LLV_4
3|01/01/2010|HISTORIAL_LLV_5

Si el parámetro de la consulta es la fecha 01/01/2010 entonces para el socio 1 existe un registro en la tabla HISTORIAL_ALQ con esa fecha. Si revisamos la tabla HISTORIAL_LLV vemos que no existe ningún registro que tenga esa fecha, entonces según la lógica que explicas el socio 1 si debe estár en la consulta final. Para el caso del socio 2 no aplica el criterio pues existe un registro con la fecha parámetro tanto en la tabla HISTORIAL_ALQ como en la tabla HISTORIAL_LLV. El socio 3 tampoco aplica, pues no tiene registros en la tabla HISTORIAL_ALQ con la fecha parámetro.

La complicación ahora viene porque en la tabla HISTORIAL_LLV hay 3 registros para el socio 1 que cumplen la condición. ¿cómo esperarías la salida?

Si se hace un join entre las tablas, pues entonces aparecería tres veces el socio 1 así:

Socio|Fecha|ID|Socio|Fecha|ID
1|01/01/2010|HISTORIAL_ALQ_1|1|02/01/2010|HISTORIAL_LLV_1
1|01/01/2010|HISTORIAL_ALQ_1|1|03/01/2010|HISTORIAL_LLV_2
1|01/01/2010|HISTORIAL_ALQ_1|1|04/01/2010|HISTORIAL_LLV_3

¿Esto es correcto? Creo que el problema viene justamente con la parte del INNER JOIN, tal vez no sea necesario hacerlos y tienes que filtrar de otra forma.

Saludos y espero tus comentarios.
Leo
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar