Lo solucioné, ¿pero por qué?

Te functiona la consulta?
select x from conceptos inner join recibos on
recibos.numerorecibo = conceptos.numerorecibo where
numreorecibo = XXX

Tienes un campo duplicado, deberia ser:
select x from conceptos inner join recibos on
recibos.numerorecibo = conceptos.numerorecibo where
RECIBOS.numreorecibo = XXX

Saludos,

Antonio Ortiz Ramirez
asesor en sistemas

www.aortiz.net




"Julio C. Briceño R." escribió en el mensaje
news:07de01c35634$4f821880$
Saludos,

Amigos tengo un típico recibo que tiene los datos
genéricos del recibo (los que salen una vez como fecha del
recibo, número de recibo, etc), tengo además los conceptos
de los recibos que pueden ser 1 o más, y los depósitos con
lo que se canceló el monto total del recibo que también
pueden ser uno o más, ahora, ¿qué pasaba?

Hacía una consulta con la que buscaba los datos de los
depósitos, asociados a un recibo.

select x from depositos inner join recibos on
recibos.numerorecibo = depositos.numerorecibo where
numerorecibo = XXX

, y otra consulta con la que buscaba los detalles

select x from conceptos inner join recibos on
recibos.numerorecibo = conceptos.numerorecibo where
numreorecibo = XXX

, ahora los depósitos me los traía en el mismo orden que
los guardé, es decir si primero se colocó el depósito del
banco YY cuenta RR ese era el primer registro que me
traía, pero con los conceptos no pasaba eso, me los traía
en el orden del código de concepto. Por ejemplo, si yo
guaradaba:

Código Descripcion
44 Pago Inicial
12 Derecho de inscripción

, me devolvía

12 Derecho...
44 Pago

¿Por qué? Las combinaciones con la tabla recibo son
iguales tanto para con depósitos como con conceptos,
además no tengo como campo clave el código del tipo de
concepto en la tabla de conceptos.

Bueno lo cierto es que como no tengo campo con el cual
pueda ordenar con un group by, decidí darle vueltas a los
tipos de combinación de SQL SERVER y encontré que uno
puede cambiar la forma (u obligar a SQL SERVER 2000) a
utilizar algo y no otra cosa que el considera adecuada,
así dí con que existen HASH, MERGE y LOOP como formas de
combinación de dos tablas, así que (desafiando los libros
en pantalla de SQL Server 2000 que te asustan con eso de
¡ESTO ES PARA ADMINISTRADORES O USUARIOS AVANZADOS! decidí
obligar a SQL SERVER 2000 al colocarle:

select x from conceptos inner (((LOOP))) join recibos on
recibos.numerorecibo = conceptos.numerorecibo where
numreorecibo = XXX

y todo funcionó bien, ahora el orden es el original

y eso fue la solución, ahora SQL SERVER no documenta bien
eso, pero ¿habrá un gran y amigable administrador que
pueda explicarme por qué el HASH (que creo que es el que
utilizaba) me devolvía la cuestión como quería?

No me preocupo por el rendimiento, son unas cincuenta
milésimas de segundos más que tarda la consulta (nada
visible para un usuario normal)

Bien si alguien llegó hasta aquí, gracias y agradezco sus
comentarios.

Julio C. Briceño R.
Caracas, Venezuela
Analista de Sistemas

Por cierto, Leonardo, felicitaciones por tu reciente nombramiento como
MVP (lo he leído en la última pasada que he hecho al grupo de vb, espero no
haberme equivocado al leer), hacía tiempo que te lo estabas mereciendo. Me
alegro


:-)



Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

Por favor, responder únicamente al foro

(Guía de netiquette del foro)
http://www.helpdna.net/bosqlfaq00.htm
http://perso.wanadoo.es/rubenvigon/foro

(FAQ's de SQL Server)
http://support.microsoft.com/defaul.../70faq.asp
http://www.helpdna.net/bosqlfaq.htm

"Leonardo Azpurua" <l a z p u r u a g (arroba) c a n t v (punto) n e t>
escribió en el mensaje news:

Hola, Paisano:

Lamento corregirle, pero una de las normas clásicas del "pensamiento
relacional" es que el orden físico de los registros no debe ser tomado en
consideración como criterio lógico al recuperar los datos.

Es interesante meterse a fondo con una herramienta. Pero tambien es
estratégicamente peligroso. Qué haces si te cae un cliente que puede

querer

comprar tu aplicación, pero a quien no le alcanza la plata para comprar

SQL

Server? Depender de un producto relativamente costoso encarece tu

solución,

y te quita mercado.

El cuento es que si bien esta vez conseguiste una solución, es una

solución

que te amarra con un proveedor específico. La solución real es agregar a

la

tabla un campo de tipo IDENTITY. Casi todos los SGBD te permiten hacer

esto.

Si luego necesitas listar por orden de llegada, simplemente agregas esa
columna como último criterio de ordenamiento y listo: tienes una solución
portable. Y en vez de escribir

"select x from conceptos inner (((LOOP))) join recibos on
recibos.numerorecibo = conceptos.numerorecibo where
numrorecibo = XXX" (guácala!)

escribes

"select x from conceptos inner join recibos on
recibos.numerorecibo = conceptos.numerorecibo where
numreorecibo = XXX ORDER BY conceptos.autoNumero"

y lo puedes correr virtualmente en cualquier servidor.

Incluso, si en vez de utilizar el INNER JOIN (que parece estandar, pero

que

tampoco lo es: los fabricantes te ponen trampas en los lugares mas

visibles)

escribes una relacion al viejo estilo:

"SELECT Conceptos.* FROM Conceptos, Recibos
WHERE Conceptos.NumeroRecibo = Recibos.NumeroRecibo
ORDER BY Conceptos.autoNumero"

ten por seguro que no vas a encontrar un proveedor donde no corra.

Siempre es bueno recordar que los "caramelitos" que nos dan los diferentes
fabricantes de SGBD, lo único que buscan es que nos amarremos (nosotros y
nuestras aplicaciones) a ellos. No se si sea bueno o malo, pero como norma
general, cuanto mas libre, mejor.

Ahora, si estas trabajando para un cliente especifico, que tiene la
intención irrevocable de seguir con su actual SGBD, no hay inconveniente

en

que emplees todos los trucos que te permita le herramienta. Y aun en ese
caso, buscar la portabilidad antes que la eficiencia, si el compromiso no

es

demasiado grande, no deja de ser buena práctica.

Salud!

Leonardo
[MS MVP - VB]
-
"Julio C. Briceño R." escribió en el mensaje
news:07de01c35634$4f821880$
Saludos,

Amigos tengo un típico recibo que tiene los datos
genéricos del recibo (los que salen una vez como fecha del
recibo, número de recibo, etc), tengo además los conceptos
de los recibos que pueden ser 1 o más, y los depósitos con
lo que se canceló el monto total del recibo que también
pueden ser uno o más, ahora, ¿qué pasaba?

Hacía una consulta con la que buscaba los datos de los
depósitos, asociados a un recibo.

select x from depositos inner join recibos on
recibos.numerorecibo = depositos.numerorecibo where
numerorecibo = XXX

, y otra consulta con la que buscaba los detalles

select x from conceptos inner join recibos on
recibos.numerorecibo = conceptos.numerorecibo where
numreorecibo = XXX

, ahora los depósitos me los traía en el mismo orden que
los guardé, es decir si primero se colocó el depósito del
banco YY cuenta RR ese era el primer registro que me
traía, pero con los conceptos no pasaba eso, me los traía
en el orden del código de concepto. Por ejemplo, si yo
guaradaba:

Código Descripcion
44 Pago Inicial
12 Derecho de inscripción

, me devolvía

12 Derecho...
44 Pago

¿Por qué? Las combinaciones con la tabla recibo son
iguales tanto para con depósitos como con conceptos,
además no tengo como campo clave el código del tipo de
concepto en la tabla de conceptos.

Bueno lo cierto es que como no tengo campo con el cual
pueda ordenar con un group by, decidí darle vueltas a los
tipos de combinación de SQL SERVER y encontré que uno
puede cambiar la forma (u obligar a SQL SERVER 2000) a
utilizar algo y no otra cosa que el considera adecuada,
así dí con que existen HASH, MERGE y LOOP como formas de
combinación de dos tablas, así que (desafiando los libros
en pantalla de SQL Server 2000 que te asustan con eso de
¡ESTO ES PARA ADMINISTRADORES O USUARIOS AVANZADOS! decidí
obligar a SQL SERVER 2000 al colocarle:

select x from conceptos inner (((LOOP))) join recibos on
recibos.numerorecibo = conceptos.numerorecibo where
numreorecibo = XXX

y todo funcionó bien, ahora el orden es el original

y eso fue la solución, ahora SQL SERVER no documenta bien
eso, pero ¿habrá un gran y amigable administrador que
pueda explicarme por qué el HASH (que creo que es el que
utilizaba) me devolvía la cuestión como quería?

No me preocupo por el rendimiento, son unas cincuenta
milésimas de segundos más que tarda la consulta (nada
visible para un usuario normal)

Bien si alguien llegó hasta aquí, gracias y agradezco sus
comentarios.

Julio C. Briceño R.
Caracas, Venezuela
Analista de Sistemas