Trabajar con fechas en una consulta

Creo que lo que te serviría es algo así

SELECT FechaPedido, IdCliente, IdPedido, Importe
FROM Pedidos, Precios
WHERE (Pedidos.IdPedido = Precios.IdPrecios)
AND ValidoDesde EXISTS (SELECT last (fecha) FROM Precios AS P
WHERE (P.ValidoDesde < Pedidos.FechaPedido) AND (Precios.IdPedido P.IdPedido))

La idea es seleccionar los datos que requerís donde el importe es el dato de
aquel registro que tiene la mayor fecha de ValidoDesde menor que la
FechaPedido.

Espero que se entienda y suerte!
Saludos!
Patricia

"Greg" escribió en el mensaje
news:265a01c33f1a$3dcb0240$
Hola,
Tengo una tabla de Precios (ValidoDesde, IdProducto,
Precio) - Los precios de los productos cambian (-->
Cambian los campos ValidoDesde & Precio) - y otra de
Pedidos (FechaPedido, IdCliente, IdPedido, IdProducto,
Cantidad,...).
Me gustaria que la consulta PedidosConsulta fuera capaz
de hallar el precio correcto del producto según la Fecha
en la que se realiza el pedido.
No basta con incluir en criterios de FechaPedido: >[ValidoDesde] ya que puedo cambiar de precio cada mes por
un mismo producto y habría muchos precios disponibles por
un pedido en una fecha X.

Ejemplo:

- Tabla de Precios:
ValidoDesde IdProducto Precio
01/10/02 Hora 7,50 ?
15/01/03 Hora 7,00 ?
30/03/03 Hora 7,25 ?


- Tabla de Pedidos
FechaPedido IdCliente IdPedido IdProducto ...
15/10/02 1 1 Hora
01/01/03 1 2 Hora
08/03/03 2 3 Hora
15/07/03 1 4 Hora

- Consulta de Pedidos que quiero obtener:
FechaPedido IdCliente IdPedido Importe
15/10/02 1 1 7,50 ?
01/01/03 1 2 7,50 ?
08/03/03 2 3 7,00 ?
15/07/03 1 4 7,25 ?

PS: Lo único que se me occure es añadir un campo
ValidoHasta en la tabla de Precios con el fin de pedir
que FechaPedido >= ValidoDesde AND (FechaPedido <ValidoHasta Or IsNull(ValidoHasta)) pero eso tiene doble
inconveniente:
- Me obliga a entrar una fecha para ValidoHasta (< de 1
día al nuevo ValidoDesde) siempre que cambio de precio.
- Me complica muchisimo los criterios de varias consultas
ya que los precios NO son los únicos datos que cambian
segun las fechas (Tambien cambian los datos de 5 o 6
tablas más) así que imaginaros las lineas de criterios en
una consulta que combine todos esos datos.

Gracias de antemano a los que gasten tiempo para
solucionarme este dolor de cabeza.



Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 2003-06-30

Si entendí bien la repuesta, eso me obligaría a entrar el
precio para cada pedido lo cual es imposible porque,
además del trabajo que da, no quiero dejar esta
responsabilidad a la persona que entra los datos.

Por otra parte parte, tengo muchas tablas con datos que
cambian en función de una fecha. Veamos lo que pretendo
con este metodo:

Mi negocio es una academia de idiomas.
- Cada profe esta relacionado con un idioma y un código
(profe 1 / profe 2) a partir de una cierta fecha. --> El
simple hecho por ejemplo de dar de alta un nuevo profe 1
de francés permite dar de baja automáticamente al antiguo
profe 1 de francés a esta fecha.

- Cada curso va relacionado con un pack de material (Pack
1 = carpeta, apuntes,...) y un precio a partir de una
cierta fecha. El hecho de entrar una nueva descripción
del pack 1 y/o un nuevo precio permitiría que cualquier
nuevo curso a partir de esta fecha vaya con el nuevo pack
y/o el nuevo precio sin tener que borrar el precio
antiguo por ello (lo cuál es imprescindible para mantener
una contabilidad correcta de los meses anteriores)

- Y puedo seguir así con muchas tablas que funcionan de
la misma forma.

¿Quizás me haya equivocado por completo en el
planteamiento para obtener el resultado que quiero?

En cuanto en las repuestas obtenidas, se me ha propuesto:
- Una subconsulta pero prefiero evitar las subconsultas
ya que si se basan sobre una consulta en lugar de una
tabla, no me permiten trabajar despues en modo diseño,
sólo en SQL.
- Una función DLast("Precio";"ListaPrecios";"IdProducto="
& IdProducto & "AND FechaPedido >= #" & ValidoDesde
& "#") la cual tiene muy buena pinta pero no me funciona.

Que seguro que alguien te indicará como resolver tu

problema, sobre todo los

que manejan codigo, pero pregunto.

No seria mas sencillo en la tabla productos tener un

solo registro por

producto con el precio actual.

Cada vez que generes un pedido, guardas en la tabla

pedidos el precio junto

al id del producto.

Esto además tiene una ventaja, y es que puedes poner

precios distintos en

distintos pedidos.

Es decir, hoy mismo, puedes vender un articulo por 5, y

venderselo a un

amigo por 4. Esto lo puedes hacer ahora?

SALUDOS.
julian-valencia-españa


.

Vamos por partes:


"Si entendí bien la repuesta, eso me obligaría a entrar el
precio para cada pedido lo cual es imposible porque,
además del trabajo que da, no quiero dejar esta
responsabilidad a la persona que entra los datos.

Mi respuesta fue pensando en bases que tengo hechas parecidas. En las tablas
de las cosas que tienen precios, llamemosles productos, las cosas que tienen
pedido las tengo solo una vez con el precio actual. Cuando genero un pedido
o factura o presupuesto, ademas de introducir el producto tambien introduzco
el precio, pero lo hago de forma automatica. Pongo como predeterminado el
valor que tiene el producto en su tabla, y en la mayoria de las ocasiones no
lo cambio. Esto para mi tiene entre otras las siguientes ventajas. No tengo
que hacer ninguna consulta para saber el precio que tenia un articulo en una
fecha determinada, si quiero, y solo si quiero, puedo ponerle otro precio y
siempre tendré guardada la factura o presupuesto tal y como la generé.
Puedes hacer varias bases de gestion, y dependiendo del usuario puedes
permitir que cambie o no el precio predeterminado.

Por otra parte parte, ..

¿Quizás me haya equivocado por completo en el
planteamiento para obtener el resultado que quiero?

Esta pregunta es dificil de contestar, y mas, con los pocos datos de los que
dispongo. Piensa que cada uno tiene una forma de gestionar, y de ver las
cosas.

Alguien dijo en estas news que algo esta bien hecho cuando funciona y da los
resultados esperados.

En cuanto en las repuestas obtenidas, se me ha propuesto:
- Una subconsulta pero prefiero evitar las subconsultas
ya que si se basan sobre una consulta en lugar de una
tabla, no me permiten trabajar despues en modo diseño,
sólo en SQL

Esto o no lo he entendido o creo que estas errado (sin h). A la hora de
hacer una consulta con access en modo grafico, sin codigo; puedes hacer la
de una tabla o de una consulta. Imaginaté que tienes una tabla de coches con
la marca y el color. Si queires seleccionar los coches de la marca A que
sean rojos, logicamente los puedes hace de golpe en una consulta sobre la
tabla coches, pero puedes hacer primero la consulta coches rojos, y despues
sobre esta consulta hacer otra que te seleccione los coches de la marca A.

SALUDOS.
julian-valencia-españa

Ya entendí lo que me quieres decir y la verdad es que
tiene mucha lógica y no había caido en ello:

Al "entrar" el precio desde la tabla de Pedidos
utilizando lo de Valor Predeterminado, ni tengo que
entrarlo a mano, ni cambia cuando al mes siguiente por
ejemplo cambio el precio en la tabla de Productos.
Tambien es verdad que puedo impedir que alguien modifique
el precio en el formulario de Pedidos bloqueando la celda
por ejemplo. (Hasta quizás pueda establecer una
contraseña para poder modificarlo, no?)

Lo mismo con mi tabla de profesores, entrando el profe
por valor predeterminado en la tabla de GruposDeClase
dónde indico la caracteristicas de cada grupo (Lugar,
Profe, Horario, etc...).

Es verdad que tiene la ventaja de dejar más libertad
(poder cobrarles el doble a los amigos por ejemplo :D ),
pero le veo una pega: A rey muerto, rey puesto
(sustituyes un precio o un profe por otro) lo cual
impide realizar un seguimiento de cada cosa: Evolución de
los precios en el tiempo, cambios de profesores, y muchas
más cosas ya que como te dije, tengo muchas tablas que
funcionan así. Por este motivo mi intención es de seguir
con este metodo: (PrecioValidoDesde, IdProducto, Precio)
o (TrabajaDesde, IdProfe, ..., IdIdioma, Profe_Nº,...).

Eso confirma lo que dijiste tú sobre que el planteamiento
es cosa de cada uno y que mientras funcione y dé los
resultados esperados..., todo vale. Aunque hay caminos
más cortos que otros (Mi primera base necesitaba de 6
tablas y 18 consultas para calcular un presupuesto para
unas clases de 2 asignaturas!!!!!)

En cuanto a eso sobre lo que estoy errado sin h, y de los
coches rojos ;), me leiste mal ya que problema no es
cuando hago una consulta sobre otra consulta (eso me
funciona perfect), sino cuando hago una SUBconsulta a
partir de una consulta.

Ejemplo:
SELECT P2.IdCliente, P2.IdPedido, P2.Importe
(SELECT Sum(Importe) From CONSULTA_Pedidos WHERE
Id.Cliente = P2.IdCliente AND IdPedido <= P2.IdPedido) AS
ImporteAcumulado
FROM CONSULTA_Pedidos AS P2;

Con este código SQL, no me deja ver la vista diseño.
Sin embargo, si me baso en la TABLA_Pedidos (que he
creado ficticia para probar) en lugar de la
CONSULTA_Pedidos, todo bien.
Qué raro pero... (Tengo Access 2002 con Windows XP)

Así que me solucionaron eso con una consulta con un DSum
que me funciona de maravilla.

Me olvidaba: Y acabo de solucionar el problema que
originaba el 1º mensaje de esta conversación remoldeando
las tablas de la base de datos de manera más practica y
eficaz. ¿O me equivoco si digo que para hacer una buena
base de datos, lo más importante es cómo planteas las
tablas y las relaciones, que de eso dependerá todo lo
demás?

Gracias por las ayudas.

Vamos por partes:


"Si entendí bien la repuesta, eso me obligaría a entrar

el

precio para cada pedido lo cual es imposible porque,
además del trabajo que da, no quiero dejar esta
responsabilidad a la persona que entra los datos.

Mi respuesta fue pensando en bases que tengo hechas

parecidas. En las tablas

de las cosas que tienen precios, llamemosles productos,

las cosas que tienen

pedido las tengo solo una vez con el precio actual.

Cuando genero un pedido

o factura o presupuesto, ademas de introducir el

producto tambien introduzco

el precio, pero lo hago de forma automatica. Pongo como

predeterminado el

valor que tiene el producto en su tabla, y en la mayoria

de las ocasiones no

lo cambio. Esto para mi tiene entre otras las siguientes

ventajas. No tengo

que hacer ninguna consulta para saber el precio que

tenia un articulo en una

fecha determinada, si quiero, y solo si quiero, puedo

ponerle otro precio y

siempre tendré guardada la factura o presupuesto tal y

como la generé.

Puedes hacer varias bases de gestion, y dependiendo del

usuario puedes

permitir que cambie o no el precio predeterminado.

Por otra parte parte, ..

¿Quizás me haya equivocado por completo en el
planteamiento para obtener el resultado que quiero?

Esta pregunta es dificil de contestar, y mas, con los

pocos datos de los que

dispongo. Piensa que cada uno tiene una forma de

gestionar, y de ver las

cosas.

Alguien dijo en estas news que algo esta bien hecho

cuando funciona y da los

resultados esperados.

En cuanto en las repuestas obtenidas, se me ha propuesto:
- Una subconsulta pero prefiero evitar las subconsultas
ya que si se basan sobre una consulta en lugar de una
tabla, no me permiten trabajar despues en modo diseño,
sólo en SQL

Esto o no lo he entendido o creo que estas errado (sin

h). A la hora de

hacer una consulta con access en modo grafico, sin

codigo; puedes hacer la

de una tabla o de una consulta. Imaginaté que tienes una

tabla de coches con

la marca y el color. Si queires seleccionar los coches

de la marca A que

sean rojos, logicamente los puedes hace de golpe en una

consulta sobre la

tabla coches, pero puedes hacer primero la consulta

coches rojos, y despues

sobre esta consulta hacer otra que te seleccione los

coches de la marca A.

SALUDOS.
julian-valencia-españa


.